почему не рекомендуется перезагружать снова после слияния?

Question

Я читаю книгу Pro Git и застреваю при перебазировании.

Ниже приведен сценарий:

Шаг 1

Шаг 2

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

Затем автор говорит:

Если вы сделаете git pull, вы создадите коммит слияния, включающий обе строки истории, и ваш репозиторий будет выглядеть так:

Я не понимаю, почему git pull автоматически объединит C4 и C7, потому что мы знаем, что обычно git pull не выполняет слияния для васи вы должны объединиться самостоятельно, так почему же в этом случае git pull объединяется для вас?

Редактировать:

Извините, я печатал и думал слишком быстро, я говорил о git fetch это не слияние автоматически, git pull слияние и git pull = git fetch + git merge.

Итак, мой вопрос: почему автор говорит:

Когдавы перебираете вещи, вы отказываетесь от существующих коммитов и создаете новые, похожие, но разные.Если вы куда-то вставляете коммиты, а другие сносят их и основывают на них работу, а затем переписываете эти коммиты с помощью git rebase и снова их подталкиваете, вашим соавторам придется заново объединять их работу, и когда вы попытаетесьвтяните их работу обратно в вашу.

Я действительно запутался, если разработчик не выполнил ребазинг после слияния, поэтому у нас есть изображение на шаге 1 в начале, затем разработчик добавилновый коммит под названием C8 сразу после C6, затем, если я вызову git pull на моем компьютере, C8 все равно нужно будет объединить с C7, так что ему все равно придется заново объединить работу,нельзя избежать, и все станет грязно, так в чем же проблема?

Answer 1

Я думаю, вы просто неправильно понимаете, что написано в книге.

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

Дело не в беспорядке, а просто в слиянии.Слияние не грязно, слияние легко.С этим проблем нет.

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

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

Answer 2

Рассмотрим git pull как псевдоним для git fetch [branch] && git merge [branch]

Answer 3

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

Учтите это: Слияние добавляет вещи впереди вас, в то время как Ребаз добавляет вещи позади вас

Так что, если вы измените вещи позади Вы, настоящие изменения.

Коммиты - это просто связанный список, указывающий на предыдущий коммит (ы), который мы называем родителями.Если вы смените родителей, это изменит сам коммит, изменив его SHA, то есть это будет совершенно новый коммит.

Скажем, у вас есть:

[some-branch]   D -> E
                       \
  [HEAD] = A -> B -> C -> E

И вам нужно получить DВы можете:

REBASE

       [some-branch]   D -> E
                         \
  [HEAD] = A' -> B' -> C' -> D -> E

или MERGE

[some-branch]   D -> E
                  \
       [HEAD] = D -> A -> B -> C -> E

(там отсутствует коммит слияния,Я знаю)

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

Почему он чище? Он не создает коммит слияния и приводит кнамного чище и разборчивее история.Безопасно только в том случае, если вы абсолютно уверены, что вы единственный, кто работает в этой ветке.

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

Answer 4

Ребазинг - это одна из операций, позволяющая изменять историю.Это означает, что вы не должны делать это в публичных ветках, где вы работаете вместе с другим разработчиком (например, разрабатывайте ветку).

Почему?

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

С другой стороны, это не означает, что вам вообще не следует использовать rebase.Я использую его ежедневно, чтобы синхронизировать свою ветку с разработчикамиЯ также всегда использую pull с опцией - rebase .

Answer 5

Как указано ответом Маурисио Мачадо , по умолчанию git pull фактически является псевдонимом операции fetch и merge.

Возможно, вы захотите настроить pull навместо этого сделайте ребаз:

$ git config --global pull.rebase true

Answer 6

Вы должны посмотреть этот вопрос здесь Git pull приводит к посторонним сообщениям "Merge branch" в журнале фиксации пользователь poke очень хорошо объясняет, почему происходит слияние.