Git push error '[удаленный отклонен] master -> master (ветка в настоящее время извлечена)'

Вчера я опубликовал вопрос о том, как клонировать Git- репозиторий с одной из моих машин на другую. Как я могу "git clone" с другой машины?,

Теперь я могу успешно клонировать Git-репозиторий из моего источника (192.168.1.2) в пункт назначения (192.168.1.1).

Но когда я сделал редактирование файла, git commit -a -m "test" и git pushЯ получаю эту ошибку в пункте назначения (192.168.1.1):

git push                                                
hap@192.168.1.2's password: 
Counting objects: 21, done.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1010 bytes, done.
Total 11 (delta 9), reused 0 (delta 0)
error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error: 
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.
error: 
error: To squelch this message and still keep the default behaviour, set
error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To git+ssh://hap@192.168.1.2/media/LINUXDATA/working
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'git+ssh://hap@192.168.1.2/media/LINUXDATA/working'

Я использую две разные версии Git (1.7 на пульте и 1.5 на локальной машине). Это возможная причина?

Источник

33 ответа

Вы можете просто преобразовать свой удаленный репозиторий в пустой репозиторий (в пустом репозитории нет рабочей копии - папка содержит только фактические данные репозитория).

Выполните следующую команду в папке удаленного хранилища:

git config --bool core.bare true

Затем удалите все файлы, кроме .git в этой папке. И тогда вы сможете выполнить git push в удаленный репозиторий без ошибок.

Источник

У меня была та же ошибка, когда я начал изучать Git. Некоторые другие ответы явно не для кого-то нового в Git!

(Я собираюсь использовать нетехнические термины, чтобы донести идею.) В любом случае, у вас есть два хранилища: одно - оригинал, который вы впервые создали, а другое - работа, которую вы только что сделали.

Прямо сейчас вы находитесь в своем рабочем репозитории и используете ветку "master". Но вы также "залогинены" в исходном репозитории в ту же "главную" ветку. Теперь, когда вы "вошли" в оригинал, Git боится, что вы можете испортить, потому что вы можете работать над оригиналом и все испортить. Так что вам нужно вернуться в исходный репозиторий и выполнить "git checkout someotherbranch", и теперь вы можете выполнить без проблем.

Надеюсь, это поможет.

Источник

Сообщение об ошибке описывает, что произошло. Более современные версии Git отказываются обновлять ветку с помощью push, если эта ветка извлечена.

Самый простой способ работать между двумя не голыми репозиториями - это либо

  1. всегда обновляйте репозитории с помощью pull (или fetch and merge) или, если нужно,

  2. нажав на отдельную ветку (ветку импорта), а затем объединяя эту ветку с главной веткой на удаленной машине.

Причиной такого ограничения является то, что операция push работает только в удаленном репозитории Git, у нее нет доступа к индексу и рабочему дереву. Таким образом, если разрешено, нажатие на извлеченную ветку изменит HEAD быть несовместимым с индексом и рабочим деревом в удаленном хранилище.

Это позволит очень легко случайно зафиксировать изменение, которое отменяет все внесенные изменения, а также очень затруднит различие между любыми локальными изменениями, которые не были зафиксированы, и различиями между новыми HEAD, индекс и рабочее дерево, которые были вызваны движением HEAD,

Источник

Резюме

Вы не можете нажать на одну извлеченную ветвь репозитория, потому что он будет связываться с пользователем этого репозитория таким образом, который, скорее всего, закончится потерей данных и истории. Но вы можете нажать на любую другую ветку того же хранилища.

Поскольку в пустых репозиториях никогда не проверяется какая-либо ветка, вы всегда можете перейти в любую ветку пустого репозитория.

Есть несколько решений, в зависимости от ваших потребностей.

Решение 1. Используйте голое хранилище

Как и предполагалось, если на одном компьютере вам не нужен рабочий каталог, вы можете перейти в пустой репозиторий. Чтобы не связываться с хранилищем, вы можете просто его клонировать:

machine1$ cd ..
machine1$ mv repo repo.old
machine1$ git clone --bare repo.old repo

Теперь вы можете отправить все, что вы хотите, на тот же адрес, что и раньше.

Решение 2. Перейдите в не проверенную ветвь

Но если вам нужно проверить код на вашем пульте <remote>, тогда вы можете использовать специальную ветвь, чтобы нажать. Допустим, в вашем локальном хранилище вы назвали свой удаленный origin а ты на ветке хозяин. Тогда вы могли бы сделать

machine2$ git push origin master:master+machine2

Тогда вам нужно объединить его, когда вы находитесь в origin удаленное репо:

machine1$ git merge master+machine2

Вскрытие проблемы

Когда ветвь извлечена, фиксация добавит новый коммит с заголовком текущей ветки в качестве его родителя и переместит голову ветки в этот новый коммит.

Так

A ← B
    ↑
[HEAD,branch1]

становится

A ← B ← C
        ↑
    [HEAD,branch1]

Но если бы кто-то мог нажать на эту промежуточную ветвь, пользователь оказался бы в том, что git называет режимом отключенной головы:

A ← B ← X
    ↑   ↑
[HEAD] [branch1]

Теперь пользователь больше не находится в branch1, без явного запроса проверить другую ветку. Хуже того, пользователь теперь находится вне какой-либо ветви, и любой новый коммит будет просто зависать:

      [HEAD]
        ↓
        C
      ↙
A ← B ← X
        ↑
       [branch1]

Гипотетически, если в этот момент пользователь проверяет другую ветвь, то этот висячий коммит становится честной игрой для сборщика мусора в Git.

Источник

Вы можете обойти это "ограничение", отредактировав .git/config на сервере назначения. Добавьте следующее, чтобы разрешить отправку репозитория git, даже если он "извлечен":

[receive]
denyCurrentBranch = warn

или же

[receive]
denyCurrentBranch = false

Первое позволит толкать, предупреждая о возможности испортить ветку, а второе просто спокойно это разрешит.

Это может быть использовано для "развертывания" кода на сервере, который не предназначен для редактирования. Это не лучший подход, но быстрый для развертывания кода.

Источник

git config --local receive.denyCurrentBranch updateInstead

https://github.com/git/git/blob/v2.3.0/Documentation/config.txt

Используйте это в репозитории сервера, и оно также обновляет рабочее дерево, если не будет перезаписи без отслеживания.

Он был добавлен в Git 2.3, как упомянуто VonC в комментариях.

Я скомпилировал Git 2.3 и попробовал. Пример использования:

git init server
cd server
touch a
git add .
git commit -m 0
git config --local receive.denyCurrentBranch updateInstead

cd ..
git clone server local
cd local
touch b
git add .
git commit -m 1
git push origin master:master

cd ../server
ls

Выход:

a
b

Ура, b получил толчок!

Источник

Мне нравится идея о том, что на удаленном компьютере все еще можно использовать репозиторий, но вместо фиктивной ветки мне нравится использовать:

git checkout --detach

Кажется, это очень новая функция Git - я использую git версии 1.7.7.4.

Источник

Я была такая же проблема. Для меня я использую Git push для перемещения кода на мои серверы. Я никогда не меняю код на стороне сервера, так что это безопасно.

В репозитории вы нажимаете, чтобы набрать:

git config receive.denyCurrentBranch ignore

Это позволит вам изменить хранилище, пока оно является рабочей копией.

После того, как вы запустите Git push, перейдите на удаленный компьютер и введите:

git checkout -f

Это позволит отразить внесенные вами изменения в рабочей копии удаленного компьютера.

Обратите внимание, что это не всегда безопасно, если вы вносите изменения в рабочую копию, на которую вы нажимаете.

Источник

Вы можете воссоздать свой репозиторий сервера и перенести его с главного локального филиала на главный сервер.

На вашем удаленном сервере:

mkdir myrepo.git
cd myrepo.git
git init --bare

ОК, из вашего местного отделения:

git push origin master:master
Источник

Что вы, вероятно, сделали, чтобы вызвать это:

Такого рода вещи случаются, когда вы отправляетесь в небольшую программу. Вы собираетесь изменить что-то, что уже работало, поэтому вы разыгрываете заклинание 3-го уровня вечной отмены:

machine1:~/proj1> git init

и вы начинаете добавлять / совершать. Но затем проект становится более активным, и вы хотите работать на нем с другого компьютера (например, с домашнего компьютера или ноутбука), поэтому вы делаете что-то вроде

machine2:~> git clone ssh://machine1/~/proj1

и это клонирует и все выглядит хорошо, и поэтому вы работаете над своим кодом с machine2.

Затем... вы пытаетесь отправить свои коммиты с machine2, и вы получите предупреждающее сообщение в заголовке.

Причина этого сообщения в том, что репозиторий git, из которого вы извлекли, был как бы предназначен для использования только для этой папки на машине1. Вы можете клонировать его просто отлично, но нажатие может вызвать проблемы. "Правильный" способ управления кодом в двух разных местах - это "голое" репо, как было предложено. Голый репозиторий не предназначен для выполнения какой-либо работы, он предназначен для координации коммитов из нескольких источников. Вот почему самый лучший ответ предлагает удалить все файлы / папки, кроме папки.git, после того, как вы git config --bool core.bare true,

Уточнение ответа с самым высоким рейтингом: во многих комментариях к этому ответу говорится что-то вроде: "Я не удалял файлы, не относящиеся к.git, с machine1, и я все еще мог фиксировать с machine2". Вот так. Однако эти другие файлы полностью "отделены" от git-репо. Иди попробуй git status там, и вы должны увидеть что-то вроде "роковой: эта операция должна быть запущена в рабочем дереве". Итак, предложение удалить файлы не так, чтобы сработал коммит с machine2; это чтобы вы не запутались и не подумали, что git все еще отслеживает эти файлы. Но удаление файлов является проблемой, если вы все еще хотите работать с файлами на компьютере1, не так ли?

Итак, что вы должны делать?

Зависит от того, сколько вы планируете по-прежнему работать на machine1 и machine2...

Если вы закончили разработку с machine1 и перенесли всю свою разработку на machine2... просто сделайте то, что предлагает самый лучший ответ: git config --bool core.bare true а затем, при необходимости, удалите все файлы / папки, кроме.git, из этой папки, поскольку они не отслеживаются и могут привести к путанице.

Если ваша работа на machine2 была единовременной, и вам не нужно продолжать там разработку... тогда не пытайтесь делать голое репо; просто ftp / rsync / scp / и т.д. ваши файлы с машины *2* поверх файлов на машине *1*, подтвердите / нажмите с машины *1*, а затем удалите файлы с машины *2*. Другие предлагали создать ветку, но я думаю, что это немного запутанно, если вы просто хотите объединить какую-то разработку, которую вы делали единовременно, с другой машины.

Если вам нужно продолжить разработку как на machine1, так и на machine2... тогда вам нужно правильно все настроить. Вам нужно конвертировать репо в голое, затем вам нужно сделать клон этого на machine1, чтобы вы могли с ним работать. Вероятно, самый быстрый способ сделать это -

machine1:~/proj1> git config --bool core.bare true
machine1:~/proj1> mv .git/ ../proj1.git
machine1:~/proj1> cd ..
machine1:~> rm -rf proj1
machine1:~> git clone proj1.git
machine1:~> cd proj1

Очень важно: поскольку вы переместили расположение репозитория с proj1 на proj1.git, вам необходимо обновить его в файле.git/config на machine2. После этого вы можете зафиксировать свои изменения с machine2. Наконец, я стараюсь хранить свои голые репозитории в центральном месте, вдали от моих рабочих деревьев (т.е. не помещайте файл "proj1.git" в ту же родительскую папку, что и "proj1"). Я советую вам сделать то же самое, но я хотел, чтобы описанные выше шаги были максимально простыми.

Источник

С помощью нескольких шагов настройки вы можете легко развернуть изменения на своем веб-сайте, используя одну строку, например

git push production

Что приятно и просто, и вам не нужно заходить на удаленный сервер и делать попытки или что-то еще. Обратите внимание, что это будет работать лучше всего, если вы не используете свой производственный контроль как рабочую ветку! (OP работал в несколько ином контексте, и я думаю, что решение @Robert Gould хорошо сработало. Это решение больше подходит для развертывания на удаленном сервере.)

Во-первых, вам нужно настроить пустой репозиторий где-то на вашем сервере, вне вашего webroot.

mkdir mywebsite.git
cd mywebsite.git
git init --bare

Затем создайте файл hooks/post-receive:

#!/bin/sh
GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f

И сделайте файл исполняемым:

chmod +x hooks/post-receive

На вашей локальной машине,

git remote add production git@myserver.com:mywebsite.git
git push production +master:refs/heads/master

Все готово! Теперь в будущем вы можете использовать git push production развернуть ваши изменения!

Кредит на это решение идет в http://sebduggan.com/blog/deploy-your-website-changes-using-git/. Ищите там более подробное объяснение того, что происходит.

Источник

Вы должны только подталкивать к голому хранилищу. Пустое хранилище - это хранилище, в котором нет проверенных веток. Если вы перейдете в пустой каталог репозитория, вы увидите только содержимое каталога.git.

Источник

Проверьте свои .git/config в целевом проекте:

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[receive]
    denyCurrentBranch = updateInstead

Если core. bare false, вы можете установить его в true:

$ git config core.bare true

а затем в вашем локальном пуш к удаленному:

git push remote_repo   // suppose the destination repo is remote_repo

это будет успешно, в remote_repo вы можете проверить версию git.

$ git log -1
commit 0623b1b900ef7331b9184722a5381bbdd2d935ba
Author: aircraft < aircraft_xxx@126.com>
Date:   Thu May 17 21:54:37 2018 +0800

и теперь вы не можете использовать git в своем "рабочем пространстве":

$ git status
fatal: This operation must be run in a work tree

вы должны установить bare.bare обратно в ложь.

$ git config core.bare false
Источник

У вас есть 3 варианта

  1. Потяните и нажмите еще раз:

    git pull; git push

  2. Нажмите в другую ветку:

    git push origin master:foo

    и объединить его на удаленном git или pull-запрос)

    git merge foo

  3. Принудительно (не рекомендуется, если вы намеренно не изменили коммиты через rebase):

    git push origin master -f

    Если все еще отказано, отключите denyCurrentBranch в удаленном хранилище:

    git config receive.denyCurrentBranch ignore
Источник

На самом деле, достаточно установить удаленную ветку на неиспользованную ветку. После того, как вы проверили пульт в другой ветке, вы можете нажать.

Источник

Более ранние версии Git, используемые для разрешения проталкивания в текущую извлеченную ветвь ненастроенного хранилища.

Оказывается, это было ужасно запутанно. Поэтому они добавили предупреждающее сообщение, которое вы видите, что также очень запутанно.

Если первый репозиторий просто действует как сервер, то преобразуйте его в пустой репозиторий, как рекомендуют другие ответы, и покончите с этим.

Однако, если вам нужно иметь общую ветку между двумя репо, которые используются, вы можете добиться этого с помощью следующей настройки

Repo1 - будет выступать в роли сервера, а также использоваться для разработки

Repo2 - будет только для разработки

Настройте Repo1 следующим образом

Создайте ветку, чтобы поделиться работой.

git branch shared_branch

Чтобы быть в безопасности, вы также должны создать $(REPO).git/hooks/update, который отклоняет любые изменения чего-либо, кроме shared_branch, потому что вы не хотите, чтобы люди копались в ваших личных ветках.

repo1/.git/hooks  (GIT_DIR!)$ cat update
#!/bin/sh
refname="$1"
oldrev="$2"
newrev="$3"

if [ "${refname}" != "refs/heads/shared_branch" ]
then
   echo "You can only push changes to shared_branch, you cannot push to ${refname}"
   exit 1
fi

Теперь создайте локальный филиал в repo1, где вы будете выполнять свою реальную работу.

git checkout -b my_work --track shared_branch
Branch my_work set up to track local branch shared_branch.
Switched to a new branch 'my_work'

(может понадобиться git config --global push.default upstream Для того чтобы git push работать)

Теперь вы можете создать repo2 с

git clone path/to/repo1 repo2 
git checkout shared_branch

На этом этапе у вас есть настройки repo1 и repo2 для работы на локальных ветвях, которые извлекают shared_branch в repo1, не беспокоясь об этом сообщении об ошибке или не синхронизируя рабочий каталог в repo1. Какой бы нормальный рабочий процесс вы ни использовали, он должен работать.

Источник

У меня была та же проблема с использованием Git для синхронизации репозиториев на моем телефоне Android и ноутбуке. Решением для меня было сделать тягу вместо толчка, как предложил @CharlesBailey.

git push origin master в Android-хранилище происходит сбой для меня с теми же сообщениями об ошибках, которые получил @hap497 из-за перехода к несложной проверке хранилища + рабочей копии.

git pull droid master на ноутбуке у меня работает репозиторий и рабочая копия. Конечно, нужно предварительно запустить что-то вроде git remote add droid /media/KINGSTON4GB/notes_repo/,

Источник

Хорошо, если вам нужен обычный удаленный репозиторий, создайте дополнительную ветку и проверьте ее. Вставьте его в одну ветку (которая не извлечена) и объедините ее с той, которая активна в данный момент позже, после выталкивания из локально.

Например, на удаленном сервере:

git branch dev
git checkout dev

На локальной установке:

git push

На удаленном сервере:

git merge dev
Источник

Использование этого для передачи его в удаленную ветку upstream решило эту проблему для меня:

git push <remote> master:origin/master

Удаленный не имел доступа к репозиторию в восходящем направлении, так что это был хороший способ получить последние изменения в этом удаленном

Источник

Вот один тест, который вы можете сделать, чтобы увидеть, как bare работа сервера:

Представьте, что у вас есть рабочая станция и сервер с размещенным на ней живым сайтом, и вы хотите время от времени обновлять этот сайт (это также относится к ситуации, когда два разработчика отправляют свою работу туда и обратно через голого посредника).

инициализация

Создайте каталог на локальном компьютере и cd в него, затем выполните эти команды:

# initialization
git init --bare server/.git
git clone server content
git clone server local
  1. Сначала вы создаете голый server каталог (обратите внимание на.git в конце). Этот каталог будет служить контейнером только для ваших файлов репозитория.
  2. Затем клонируйте свой репозиторий сервера во вновь созданный content каталог. Это ваш каталог live/production, который будет обслуживаться вашим серверным программным обеспечением.
  3. Первые два каталога находятся на вашем сервере, третий - локальный каталог на вашей рабочей станции.

Workflow

Теперь вот основной рабочий процесс:

  1. Введите local каталог, создайте несколько файлов и зафиксируйте их. Наконец, отправьте их на сервер:

    # create crazy stuff
git commit -av
git push origin master

  2. Теперь введите content каталог и обновить содержимое сервера:

    git pull

  3. Повторите 1-2. Вот content может быть другой разработчик, который может подтолкнуть к серверу, и local как вы можете от него оторваться.

Источник

Я должен был повторно запустить git --init в существующем голом хранилище, и это создало .git каталог внутри дерева репозитория - я понял, что после ввода git status там. Я удалил это, и все снова было хорошо:)

(Все эти ответы великолепны, но в моем случае это было что-то совершенно другое (насколько я вижу), как описано.)

Источник

Вам нужно будет изменить файл конфигурации на удаленном сервере, как только вы создадите пустой (пустой) репозиторий, скажем,

root@development:/home/git/repository/my-project# cat config

там вы увидите

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

Вы превратите это значение от ложного до истинного, и я удалил logallrefupdates = true (не уверен в его использовании!)

в

[core]
repositoryformatversion = 0
filemode = true
bare = true

Вы можете проверить следующее

$ git remote show origin
* remote origin
Fetch URL: my-portal@development:/home/XYZ/repository/XYZ
Push  URL: my-portal@development:/home/XYZ/repository/XYZ
HEAD branch: (unknown)

Эта ветка HEAD: (неизвестно) будет показана, если вы не можете нажать. Так что, если ветка HEAD неизвестна, вы должны изменить голое значение на true, а после успешного нажатия вы можете повторно использовать

git remote show origin

и ты увидишь

 HEAD branch: master
Источник

Я уверен, что большинство людей, просматривающих этот вопрос, остановятся на первых двух огромных ответах, но я все же хотел бы предложить свое решение.

У меня была настройка веб-проекта Eclipse + EGit при обнаружении описанной ошибки. Что мне помогло, так это простое использование приложения GitHub, которое, казалось, волшебным образом решило проблему. В то время как EGit всегда отказывался от пуша, настольное приложение GitHub просто пожало плечами и подтолкнуло мои изменения. Может быть, он обрабатывает ситуацию с несколькими входами более изящно.

Источник

Статья, которую я нашел, которая может быть полезна другим, - это Git за 5 минут.

У меня был проект XCode под управлением версией Git, который я хотел передать в виртуальный распределенный Ethernet (VDE), который у меня есть в DC. VDE работает Centos 5.

Ни одна из статей, которые я читал о Git, не говорила о голых репозиториях. Все это звучало так просто, пока я не попробовал то, что, по моему мнению, должно быть легко, исходя из опыта SVN.

Предложения здесь, чтобы сделать удаленный репозиторий голым, работали. Еще лучше для моих требований было клонировать проект Xcode, чтобы projectname.gitскопируйте это на удаленный сервер; затем толчки волшебным образом сработали. Следующим шагом будет получение Xcode для отправки без ошибок о коммитах, но пока я в порядке, делая это из терминала.

Так:

cd /tmp (or another other directory on your system)<br/>
git clone --bare /xcode-project-directory projectname.git<br/>
scp -r projectname.git sshusername@remotehost.com:repos/<br/>

Чтобы отправить изменения из вашего проекта Xcode после фиксации в Xcode: 

cd /xcode-project-directory<br/>
git push sshusername@remotehost.com:repos/projectname.git<br/>

Я уверен, что есть более плавный и изощренный способ сделать это, но как минимум это работает. Просто так все понятно, вот некоторые пояснения: /xcode-project-directory каталог, в котором хранится ваш проект xcode /Users/Your_Name/Documents/Project_Name, имя проекта - буквально название проекта, но это может быть любое название. Git не волнует, ты будешь.

Чтобы использовать scp, вам нужно иметь учетную запись пользователя на удаленном сервере, которому разрешен доступ по SSH. Любой, у кого есть собственный сервер, будет иметь это. Если вы используете виртуальный хостинг или тому подобное, вам может не повезти.

remotehost.com это имя вашего удаленного хоста. Вы можете так же легко использовать его IP-адрес. Просто для большей ясности я использую Gitosis на удаленном хосте с SSH-ключами, поэтому мне не нужно вводить пароли при нажатии. В статье " Хостинг Git-репозиториев, простой (и безопасный) способ" рассказывается, как все это настроить.

Источник

Если вы используете ключ SSH для подключения к GitHub, убедитесь, что ваш ключ SSH все еще находится в настройках вашего профиля. По какой-то причине мой ключ там был очищен, и я не смог отправить его в свою главную ветку. Я просто добавил свой SSH-ключ вsettings/SSH keysснова.

Команда для просмотра существующего ключа:cat ~/.ssh/id_rsa.pub

Источник

Я только что столкнулся с этой проблемой в Git-репозитории развертывания на Heroku.

Я не знаю, почему у Heroku на их стороне находится непокрытое хранилище, но в качестве обходного пути я смог сбросить настройки удаленного хранилища и выполнить повторную загрузку.

Вы не должны использовать копию своего хранилища Heroku в качестве единственного git-хранилища для совместной работы, но на всякий случай я четко скажу: не делайте этого, если вы не уверены, что у вас есть полная копия вашего хранилища, надежно хранящаяся где-то, кроме Heroku. Выполнение сброса приведет к удалению содержимого хранилища.

Для сброса:

  1. Установите инструментальный пояс Heroku (который содержит клиент командной строки), если вы этого еще не сделали.

  2. Установите плагин heroku-repo, если вы этого еще не сделали.

    heroku plugins:install https://github.com/heroku/heroku-repo.git

  3. Сделайте сброс, который удалит хранилище и создаст новый, пустой

    heroku repo:reset

  4. Нажмите на пульт Heroku, как обычно; это перезагрузит все.

Источник

Лучший способ сделать это:

mkdir ..../remote
cd ..../remote
git clone --bare .../currentrepo/

Это приведет к клонированию хранилища, но не создаст никаких рабочих копий в .../remote, Если вы посмотрите на пульт, вы увидите один созданный каталог, называемый currentrepo.git, что, вероятно, то, что вы хотите.

Затем из вашего локального репозитория Git:

git remote add remoterepo ..../remote/currentrepo.git

После внесения изменений вы можете:

git push remoterepo master
Источник

Позвольте мне добавить свои 50 центов, потому что ответ с наибольшим количеством голосов /questions/20920581/git-push-error-udalennyij-otklonen-master-master-vetka-v-nastoyaschee-vremya-izvlechena/20920587#20920587 предлагает преобразование удаленного repw в голый репозиторий, и что, если это не то, что я хочу?

В конце концов, я должен иметь тот же код на удаленной машине, а не просто скопления байтов где-то в подвешенном состоянии .git.

Второе решение (на момент написания этой статьи) /questions/20920581/git-push-error-udalennyij-otklonen-master-master-vetka-v-nastoyaschee-vremya-izvlechena/20920585#20920585 выполняет свою работу, но после тестирования мне пришлось постоянно переключаться между ветвями на удаленной машине, чтобы «освободить» ветка, которую я хочу отправить с моей локальной машины.

Это сработало для меня:

Еще одно решение, которое работало у меня до сих пор, не мое, это заслуга пользователя @kxr, который прокомментировал первое решение.

На удаленной машине вы должны выполнить эту команду в каталоге репо.

git config receive.denyCurrentBranch updateInstead

После этого вы сделали!

Очевидно, что у этого решения могут быть некоторые недостатки, но для простой задачи синхронизации вашего локального машинного кода с вашим удаленным репозиторием этого, вероятно, достаточно.

Я был бы признателен, если бы кто-нибудь объяснил в комментариях, почему совершенно нормально создать новый репозиторий на github, связать с ним свою локальную папку и начать делатьgit push origin masterбез ошибок.

Но попытка сделать то же самое с репозиторием на удаленном сервере приводит к ошибке:

! [remote rejected] master -> master (branch is currently checked out)

Источник

На всякий случай, если кто-то найдет это полезным. Для меня это была проблема с разрешениями на git-сервере. Я проверил проект с самого начала и отправил простой файл, а затем я получил "Push rejected: Push to origin/master был отклонен"

Источник

Для меня рабочее решение это:

НА УДАЛЕННОМ:

git checkout -b some_tmp_name

НА МЕСТНОМ

git push

НА УДАЛЕННОМ:

git checkout master
git branch -d some_tmp_name

Но это не реальное решение, это просто обходной путь.

Источник
Другие вопросы по тегам