git push -force-with-lease vs. -force

Я пытаюсь понять разницу между

git push -f

а также

git push --force-with-lease

я предполагаю, что последний только толкает к удаленному, если пульт не фиксирует, что локальная ветка не имеет?

Если есть лучший способ сформулировать вопрос, lmk, но, надеюсь, это ясно.

Ответ 1

force перезаписывает удаленную ветвь с вашей локальной ветвью.

--force-with-lease - более безопасный вариант, который не будет перезаписывать какую-либо работу на удаленной ветке, если к удаленной ветке добавлено больше коммитов (другим членом команды или сотрудником или кем вы были). Это гарантирует, что вы не перезапишете кого-либо, используя силу нажатия.

Я думаю, что ваша общая идея, окружающая команду, правильная. Если удаленная ветвь имеет то же значение, что и удаленная ветвь на локальном machine-, вы перезаписываете удаленный. Если он не имеет того же value-, это указывает на изменение, которое кто-то еще сделал в удаленной ветке во время работы над вашим кодом и, таким образом, не будет перезаписывать какой-либо код. Очевидно, что если в удалении есть дополнительные коммиты, то значения не будут одинаковыми.

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

Я уверен, что вы посмотрели документы, но здесь может быть более многословное объяснение:

https://git-scm.com/docs/git-push

Ответ 2

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

Например. У нас есть проект с веткой функций, над которой будут работать Алиса и Боб. Они оба клонируют этот репозиторий и начинают работу. Алиса вначале завершает свою часть функции и переносит ее в главный репозиторий. Это все хорошо. Боб также заканчивает свою работу, но, прежде чем поднять ее, он замечает, что некоторые изменения были объединены с мастером. Желая сохранить чистое дерево, он выполняет ребаз против ветки master. Конечно, когда он пойдет, чтобы подтолкнуть эту перебазированную ветку, она будет отклонена. Однако, не понимая, что Алиса уже подтолкнула ее работу, он выполняет толчок --force. К сожалению, это удалит все записи об изменениях Алисы в центральном хранилище.

--force -with-lease отказывается обновлять ветку, если только мы не ожидаем того состояния; то есть никто не обновил ветку вверх по течению. На практике это работает путем проверки того, что ссылка на исходный код - это то, что мы ожидаем, потому что ссылки являются хешами и неявно кодируют цепочку родителей в их значение.

Вот хороший пост, касающийся git push --force и git push --force -with-lease.

Ответ 3

Ищете ответ из достоверных и/или официальных источников.

Упомянутое torek в комментариях и в его другом ответе далее иллюстрируется источниками самого Git.,

последний только проталкивает к удаленному, если удаленный не имеет коммитов, которых нет в локальной ветки?

Эта функция была представлена в этом коммите (декабрь 2013 г., Git v1.8.5-rc0)

--force-with-lease будет защищать все удаленные ссылки, которые будут обновлены, требуя, чтобы их текущее значение было таким же, как некоторые разумные значения по умолчанию, если не указано иное;

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

Итак, "аренда" означает:

"force-with-lease": вы предполагаете, что взяли в аренду эту ссылку, когда выбирали ее, чтобы решить, какой должна быть перебазированная история, и вы можете отменить ее, только если аренда не была нарушена.

В источниках до сих пор упоминается "cas":

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

Вторая попытка назвала его "lockref" (потому что это концептуально похоже на нажатие после взятия блокировки), но слово "блокировка" было ненавистно, потому что оно подразумевало, что оно может отклонить push другими, что не работает так, как эта опция.

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

Итак: "git push --force-with-lease против --force"

Как я упоминал в "push --force-with-lease по умолчанию", как упоминается в Git 2.13 (Q2 2017), параметр --force-with-lease можно игнорировать, если фоновый процесс (например, тот, который вы найдете в IDE с работает плагин Git) git fetch origin.
В этом случае преобладает --force.

Ответ 4

Предполагая, что любые предварительные приемные сигналы на сервере принимают push, это всегда будет иметь успех:

git push --force

Если перед этим выполняется конкретная проверка на стороне клиента:

git push --force-with-lease

Вы можете выполнить конкретную проверку самостоятельно. Здесь алгоритм "проверки аренды":

Выясните свою текущую ветку.
Запустите git for-each-ref refs/remotes. Обратите внимание на идентификатор фиксации, который, по вашему мнению, отвечает клиенту git, соответствует состоянию вашего текущего ветки.

Например, если вы находитесь на ветке "foo", обратите внимание на код фиксации, связанный с "refs/remotes/origin/foo".

Определите фактический идентификатор фиксации удаленной ветки на верхнем сервере git прямо сейчас.
Только пусть "git push" продолжится, если согласованные с вами действия с шага 2 и шага 3 согласуются. Другими словами, продолжайте действовать только в том случае, если ваше местное представление git clone вверх по течению согласуется с фактическим восходящим потоком.

Здесь печальное значение: поскольку git fetch обновляет все ссылки refs/refotes/origin/* до последних версий, эта комбинация команд по существу идентична git push --force:

git fetch

# The command below behaves identically to "git push --force"
# if a "git fetch" just happened!

git push --force-with-lease

Чтобы обойти эту неотъемлемую слабость в git push --force-with-lease я стараюсь никогда не запускать git fetch. Вместо этого я всегда запускаю git pull --rebase всякий раз, когда мне нужно синхронизировать с восходящим git pull --rebase, поскольку git pull обновляет только один ref при refs/remotes, сохраняя при этом "аренду" --force-with-lease.

Ответ 5

Сила с арендой не обязательно безопасна. Это просто работает, как сказала Сильви. Одно замечание: в git ветка - это просто указатель на коммит. И коммиты указывают на ноль или более родительских коммитов. Даже если вы полностью изменили ветку с помощью жесткого git-сброса и принудительного пуша или пуша с - - force-with-lease, не желая этого, это не обязательно является большой проблемой. Вы можете использовать свой локальный git reflog, чтобы увидеть, как ваш локальный совет по веткам (Где был HEAD в то время?) Изменился, сбросить и снова нажать на ветку. Тогда вы потеряете только новые коммиты в удаленной ветке, но даже они могут быть восстановлены членами команды.