Правило Git заключается в том, что вы никогда не должны пытаться изменить историю после того, как она была опубликована, опубликована или отправлена. Конечно, вы можете это сделать, если действительно хотите и у вас есть достаточные разрешения, но это следует делать с большой осторожностью, поскольку это может навредить другим людям.
Теперь, к счастью, когда у вас есть типичное развертывание Git с одним исходным репозиторием (источником), который является источником всего хорошего и истинного во вселенной, вы можете использовать git pull --rebase сколько душе угодно, и это будет совершенно безопасно и, на мой взгляд, дать вам гораздо более разумную (то есть линейную) историю. Я и моя команда постоянно его используем.
Однако, если вы начинаете использовать несколько пультов дистанционного управления и начинаете делать git pull --rebase <arguments> так, чтобы вы больше не переустанавливали один и тот же целевой объект каждый раз, или начинаете подталкивать свою ветку к альтернативным репозиториям перед запуском git pull --rebase с вашим основным восходящим потоком, тогда можно начать нарваться на неприятности.
Каждый раз, когда вы делитесь своими изменениями с другим удаленным / репозиторием, а затем изменяете эти изменения (для значений изменения, равных изменению SHA, родителя и т. Д., Даже если сообщение / содержимое фиксации не изменилось), вы можете испортить человека у кого были старые изменения.
До тех пор, пока вы не выйдете за рамки здравомыслия rebase, git pull --rebase будет вам очень хорошо.
Это, эээ, не отвечает на вопрос о разнице между git pull --rebase и git fetch && git rebase @{u}. Я просто продолжу и скажу, что я не замечаю никакой разницы, и если она есть, она достаточно тонкая, чтобы я не заметил ее за те годы, что использовал Git. Возможно, в том, что система определяет правильный репозиторий, который ваша ветка должна получить, если у вас есть несколько репозиториев, а «origin» не является восходящим потоком этой ветки?
И даже если вы очень сильно ошибетесь с git-rebase, вы, конечно, можете легко вернуться к исходной среде до перебазирования с помощью git log -g и / или git reset --hard ORIG_HEAD. Только не выполняйте принудительные нажатия (по умолчанию они запрещены почти на всех серверах Git), и вы будете счастливы.
ИЗМЕНИТЬ
Со временем мое понимание расширилось. git pull --rebase вызывает git rebase для выполнения работы по перебазированию, поэтому в этом смысле между ними нет никакой разницы. Однако на самом деле git-pull вызывает git rebase --onto @{u} $(git merge-base HEAD @{u}@{1})
Хорошо, этот синтаксис ("@ {u} @ {1}"), возможно, немного непрозрачен и упрощает загрузку, но дело в том, что он выясняет, какой была база слияния для восходящего потока ПЕРЕД он выполнил команду выборки. Вы спросите, какая разница?
Ну, в обычном случае нет. Однако, если вы меняете направление восходящего потока или если сам восходящий поток был перебазирован, довольно много. Если апстрим был переписан, а затем вы сделали git rebase @{u}, вы могли быть очень недовольны и могли получить двойные коммиты или конфликты в зависимости от того, насколько старые коммиты были переписаны.
Однако с магией, лежащей в основе git pull --rebase, только ваши и только ваши коммиты будут применяться поверх @ {u}.
Хорошо, это тоже является упрощением. Если апстрим выполнил перебазирование, начиная с 100 коммитов назад (но на самом деле в истории более 101 коммитов) и вы выполнили git fetch до выполнения git pull --rebase, то Git не будет в состоянии точно определить, какова правильная историческая база слияния, чтобы выяснить, каковы ваши локальные коммиты.
В результате git fetch считается вредным (когда у вас есть локальные коммиты и апстрим перезаписан). Однако реальное практическое правило - «никогда не пытайтесь изменить историю после того, как она была опубликована, опубликована или отправлена», с чего я начал.
TL;DR:
git fetch считается вредным (поэтому используйте git pull --rebase); и никогда не пытайтесь изменить историю после того, как она была опубликована, опубликована или отправлена (потому что, помимо прочего, это может git fetch быть вредным).
person
Seth Robertson
schedule
08.06.2011
git pullзвучит так, будто все может пойти не так, как надо. Но описание в книге звучит так, будто вам нужно приложить усилия, чтобы облажаться с ребейзингом. - person Ryan Lundy schedule 09.06.2011git fetchдля обновления моего представления об удаленном репо, а затем просматриваю раскрывающуюся историю и решаю, что я хочу сделать. (Обычно я добавляюgit rebase.) - person Ryan Lundy schedule 20.03.2013