Git pull приводит к посторонним сообщениям "Merge branch" в журнале коммитов

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

---

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

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

...->C1

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

...->C1->C2

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

...->C1->C3

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

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

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

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

Коммит слияния отсутствует. История стала более линейной.

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

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

Вы можете установить значение branch.autosetuprebase = всегда, чтобы 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 показывает коммиты слияния.

Answer 3

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

git pull --rebase

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

Answer 4

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

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

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

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

Answer 5

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

git stash
git pull
git stash pop

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