Git pull.rebase это, возможно, опасная операция

на git-config документация информация о pull.rebase:

тянет.rebase

если true, перебазируйте ветви поверх извлеченной ветви, вместо слияния ветви по умолчанию с пульта дистанционного управления по умолчанию, когда "git pull" - это бег. См. " филиал..rebase " для установки этого на на ветке основе.

Примечание: это, возможно, опасная операция; не используйте его, если вы понять последствия (см. git-rebase(1) для деталей).

может ли кто-нибудь подробно описать, что делает "NOTE: this is a possibly dangerous operation; do not use it unless you understand the implications (see git-rebase(1) for details)" в смысле?

13
git git-pull git-rebase

3 ответов

предположим, у вас есть эти репозитории Git:

  • ваше личное РЕПО, сидящее на вашем рабочем компьютере;
  • ваше публичное РЕПО,you, где-то прошла;
  • основной РЕПО, origin, который является основным деревом разработки.

вы работаете над чем-то и сделали два коммита A и B. Вы опубликовали их в своем публичном РЕПО. В то же время, origin имеет еще одну фиксацию Z.

     /-A-B master, you/master
o-o-o
     \-Z origin/master

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

          /-C-D-E colleague/master
     /-A-B master, you/master
o-o-o
     \-Z origin/master

теперь вы хотите добавить свои два полностью протестированных коммита поверх origin/master. Вы получаете от origin и сделать перебазирования (что эквивалентно git pull --rebase или git pull С тяги.набор опций rebase). Это создает два новая commits. Вы толкаете их в свое публичное РЕПО и origin. Чтобы еще больше все усложнить, предположим, что новая фиксация F нажата на origin после этого.

     /-A-B-C-D-E colleague/master
o-o-o
     \-Z-A'-B'-F master, you/master, origin/master

теперь проблема в том, что у вашего коллеги есть работа, основанная на двух "устаревших" коммитах, и чтобы избежать дальнейших осложнений (конфликтов при слиянии, запутывании истории), он должен перебазировать свою ветку поверх B' (скажем, он не хочет F). Ты должна рассказать ему об этом, иначе он не заметит, что ты сделала.

            /-C-D-E colleague/master
o-o-o-Z-A'-B'-F master, you/master, origin/master

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

     /-A-B-C-D-E
o-o-o           \
     \-Z-A'-B'-F-M colleague/master, origin/master

у вас есть два коммита A и B, хотя и с разными именами. Историю становится все труднее читать, и вы будет сталкиваются с ужасными конфликтами слияния. И помните, что этот пример довольно прост. Если над проектом работают десятки людей, и origin движется быстро, история скоро станет полным беспорядком.

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

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

15

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

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

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

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

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

вы можете узнать больше о перебазировании из Переписывание Истории на бесплатный онлайн Pro Git book и конечно официальное ядро Linux Git документация rebase отлично, а также.

9

стоит отметить, что "злое изменение" от "зло слияния" можно потерять молча при перезагрузке "злого слияния", содержащего" злое изменение", которое не конфликтует с другими коммитами.

0