Git pull приводит к появлению посторонних сообщений «Merge branch» в журнале фиксации

Я работаю с другим разработчиком над проектом, и мы используем Github в качестве удаленного репозитория. Я на Mac использую git 1.7.7.3, он в Windows использует git 1.7.6.

Вот что происходит

1. Один из нас (назовем его разработчиком A, но неважно, какой) отправляет набор коммитов на GitHub.
2. Другой (разработчик B) делает некоторые локальные коммиты.
3. B делает а git pull.
4. B делает а git push.
5. Глядя на журнал истории коммитов, я вижу «master» ветки слияния на github.com:foo/bar

Журнал фиксации со временем засоряется сообщениями «Объединить ветвь», а также показывает, что разработчик Б фиксирует изменения, сделанные разработчиком А. Единственный способ, который мы нашли для предотвращения этой проблемы, - это выполнить git pull --rebaseна шаге 3, но я не знаю, какие побочные эффекты представит перебазирование. Я впервые работаю над репозиторием git для нескольких разработчиков, так что это нормальное поведение? Есть мысли, как решить эту проблему?

Фиксация, которую вы видите, прекрасна. A pullэффективно запускается, git fetchа затем, git mergeкогда вы запускаете, обычно происходит слияние git pull.

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

Вы видите коммиты для объединения двух (или более) веток. Совершенно нормально иметь коммит, который ничего не делает, кроме слияния нескольких веток. Фактически, это очень ясно показывает, когда у вас есть фиксация слияния, которая объединяет ветви при просмотре истории. По сравнению с перебазированием, слияние также позволяет вам эффективно видеть исходную историю по мере ее разработки, включая фактические сосуществующие ветки.

Итак, короче: да, коммиты слияния - это прекрасно, и вам не стоит о них беспокоиться.

Этот ответ был изменен, поскольку мое понимание, диаграммы и выводы были неверными.

git pullвызывает коммиты слияния, потому что происходит слияние git. Это можно изменить, установив в ваших ветках использование перебазирования вместо слияния. Использование перебазирования вместо слияния при вытягивании обеспечивает более линейную историю для общего репозитория. С другой стороны, коммиты слиянием показывают параллельную разработку ветки.

Например, два человека работают в одной ветке. Ветвь начинается как:

...->C1

Первый человек заканчивает свою работу и толкает в ветку:

...->C1->C2

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

...->C1->C3

Если вытягивание настроено на слияние, репозиторий второго лица будет выглядеть так.

...->C1->C3->M1
      \      /
       ->C2->

Где M1 - это фиксация слияния. История этой новой ветки будет отправлена ​​в репо. Если бы вместо этого был установлен pull для перебазирования локального репо, это выглядело бы так:

...->C1->C2->C3

Нет фиксации слияния. История сделана более линейной.

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

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

Вы можете установить branch.autosetuprebase = always, чтобы git автоматически устанавливал ваши удаленные ветки как rebase вместо master.

git config --global branch.autosetuprebase always

Этот параметр заставляет git автоматически создавать параметр конфигурации для каждой удаленной ветки:

branch.<branchname>.rebase=true

Вы можете установить это самостоятельно для своих удаленных веток, которые уже настроены.

git config branch.<branchname>.rebase true

Я хотел бы поблагодарить @LaurensHolst за вопросы и продолжение моих предыдущих утверждений. Я определенно узнал больше о том, как git работает с коммитами pull и merge.

Для получения дополнительной информации о коммитах слияния вы можете прочитать участие в проекте в ProGit-Book . Раздел Private Small Team показывает коммиты слияния.

Ты можешь сделать:

git pull --rebase

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

На самом деле есть гораздо более простой ответ. Просто пусть разработчик Б потянет ДО того, как сделать коммит. Это предотвратит эти коммиты слияния, поскольку они вызваны историей, которую вы создали в своем локальном репо, из вашей локальной фиксации, пытающейся слиться с историей коммитов в удаленном репо. Если при вытягивании вы получаете сообщение вроде «изменения будут перезаписаны», это просто означает, что вы оба коснулись одного и того же файла, поэтому сделайте следующее:

git stash
git pull
git stash pop

тогда вы можете разрешить любые конфликты слияния, если они есть.

Выполнение git pull вставит сообщения «Объединить ветку», это именно то, что он делает. Выполнив git pull, вы объединили удаленную ветку с локальной веткой.

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

Насколько я знаю, именно так работает git, и другого пути нет.

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