Правило с Git состоит в том, что вы никогда не должны пытаться изменить историю после того, как она была опубликована, опубликована или отправлена.Конечно, вы можете сделать это, если вы действительно хотите иметь достаточные разрешения, но это должно быть сделано с большой осторожностью, поскольку это может испортить других людей.
Теперь, к счастью, когда у вас есть типичное развертывание Git сЕдинственный репозиторий (источник), который является источником всего хорошего и истинного во вселенной, вы можете использовать git pull --rebase для вашего сердца, и это будет совершенно безопасно и, на мой взгляд, даст вам гораздо более вменяемый (смысллинейная) история.Я и моя команда используем его постоянно.
Однако, если вы начинаете использовать несколько пультов дистанционного управления и начинаете делать git pull --rebase <arguments>, чтобы вы больше не перебирались на одну и ту же цель каждый раз или начинаете подталкивать свою ветвь к альтернативным репозиториям до запуска git pull --rebase с вашим основным апстримом - тогда вы можете столкнуться с проблемами.
В любое время, когда вы делитесь своими изменениями с другим удаленным / репозиторием, а затем изменяете эти изменения (для значенийизменение равным изменению SHA, родителя и т. д., даже если сообщение / содержимое фиксации не изменилось), вы можете испортить человека, у которого были старые изменения.
Пока вы не упадетевне конверта здравого смысла, git pull --rebase будет очень хорошо для вас.
Это, например, не отвечает на вопрос о разнице между git pull --rebase и git fetch && git rebase @{u}.Я просто продолжу и скажу, что я не знаю ни о какой разнице, и если она есть, она достаточно тонкая, чтобы я не замечал ее в те годы, когда использовал Git.Возможно в том, что система определяет правильный репозиторий, который должна получить ваша ветка, если у вас есть несколько репозиториев, а «origin» не является последним потоком этой ветки?
И даже если вы действительно сильно ошибаетесь с git-rebaseКонечно, вы можете легко вернуться в исходную среду предварительной ребазировки с помощью git log -g и / или git reset --hard ORIG_HEAD.Только не делайте принудительных нажатий (по умолчанию запрещено почти на всех серверах Git), и вы будете счастливы счастливы.
EDITED
Со временем мое понимание расширилось.git pull --rebase призывает git rebase выполнить ребазинг, поэтому в этом смысле между ними нет никакой разницы.Однако git-pull на самом деле вызывает git rebase --onto @{u} $(git merge-base HEAD @{u}@{1})
OK, этот синтаксис ("@ {u} @ {1}"), возможно, немного непрозрачен и упрощает загрузку, но дело в том, что онвыясняет, какая база слияния находилась в восходящем направлении ДО она запустила команду fetch.Вы спрашиваете, какая разница?
Ну, в обычном случае нет.Однако, если вы меняете, куда указывает восходящий поток или если сам восходящий поток был перебазирован, довольно много.Если upstream был переписан, а затем вы сделали 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).