Что это за предупреждение Git при отправке изменений в удаленный репозиторий?

Question

Описание немного лаконично. Я просто добавил файл в свою локальную главную ветку и перенес его в удаленное хранилище. Любая идея, почему это происходит?

warning: updating the current branch
warning: Updating the currently checked out branch may cause confusion,
warning: as the index and work tree do not reflect changes that are in HEAD.
warning: As a result, you may see the changes you just pushed into it
warning: reverted when you run 'git diff' over there, and you may want
warning: to run 'git reset --hard' before starting to work to recover.
warning: 
warning: You can set 'receive.denyCurrentBranch' configuration variable to
warning: 'refuse' in the remote repository to forbid pushing into its
warning: current branch.
warning: To allow pushing into the current branch, you can set it to 'ignore';
warning: but this is not recommended unless you arranged to update its work
warning: tree to match what you pushed in some other way.
warning: 
warning: To squelch this message, you can set it to 'warn'.
warning: 
warning: Note that the default will change in a future version of git
warning: to refuse updating the current branch unless you have the
warning: configuration variable set to either 'ignore' or 'warn'.   

Answer 1

с Git 2.3.0, февраль 2015

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

Но чтобы быть более безопасным в этой операции, теперь вы можете (с Git 2.3.0, февраль 2015 г.) сделать в этом удаленном репо:

git config receive.denyCurrentBranch updateInstead

Это более безопасно, чем конфигурация receive.denyCurrentBranch=ignore: оно разрешит толчок, только если вы не отменяете изменение в процессе.

См. коммит 1404bcb от Йоханнес Шинделин (dscho) :

receive-pack: добавить еще один параметр для receive.denyCurrentBranch

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

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

Новая опция:

updateInstead

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

---

commit 4d7a5ce добавляет больше тестов и упоминает:

В предыдущем тесте проверялся только тот случай, когда путь, который должен быть обновлен с помощью push-to-deploy, имеет несовместимое изменение в рабочем дереве цели, которое уже добавлено в индекс, но сама функция хочет требовать рабочего Дерево должно быть намного чище, чем проверено.

Добавьте еще несколько тестов для защиты функции от будущих изменений, которые по ошибке (с точки зрения изобретателя функции) ослабляют требование чистоты, а именно:

• Изменение только в рабочем дереве, но не в индексе, все еще должно быть защищено;
• Не защищенный файл в рабочем дереве, который будет перезаписан при развертывании push-to-deploy, должен быть защищен;
• Изменение, которое делает файл идентичным тому, что выдвигается, по-прежнему является изменением, которое необходимо защитить (т. Е. Требование к чистоте функции более строгое, чем проверка).

Кроме того, проверьте, что изменение только статистики для рабочего дерева не является причиной для отклонения push-to-deploy.

с Git <2.3.0, февраль 2015 </h2> Наиболее распространенный подход - создать пустой репозиторий из не-пустого репозитория, и иметь удаленные / локальные не-голые репозитории git, указывающие на только что созданный пустой репозиторий.

Answer 2

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

Это очень сбивает с толку, потому что теперь он думает, что проверил последнюю версию ветки, когда, на самом деле, вы только что обновили ветку до более новой версии. Поэтому, когда он теперь запускает git commit, , его коммит по существу вернет все коммиты, которые вы только что нажали. И когда он запускает git diff, он увидит противоположность всему, что вы только что нажали, даже если он, возможно, даже ничего не изменил.

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

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

Answer 3

Это та же проблема, что и Этот вопрос , решение состоит в том, чтобы использовать git init --bare или git clone --bare.