Git: слияние с часто обновляемой удаленной веткой?

Question

Просто интересно, какова обычная практика слияния обратно с мастером, когда ГОЛОВКА, вероятно, будет обновлена ​​снова с момента последнего извлечения перед слиянием. Чтобы проиллюстрировать на следующей диаграмме, M - это предполагаемая точка слияния, но поскольку главный HEAD обновляется до A1 к тому времени, когда M зафиксирован и готов к отправке, M1 станет новой предполагаемой точкой слияния, другими словами, новым слиянием. должно быть предпринято

master-----A----A1---...
            \     \
             M     M1
            /     /
local------B------

Обратите внимание, что я предпочел бы не объединять М и А1, потому что там могут быть А2, А3, и если проблема повторяется, для меня это выглядит слишком грязно с дополнительными непреднамеренными слияниями. Если локальные изменения в достаточной степени независимы от изменений в master, иногда я просто перебазирую их поверх master, что я считаю более простым решением. Но в других случаях я действительно надеюсь, что есть какой-то способ, которым я могу «повторно» использовать работу по слиянию, которую я проделал для M, для M1.

Answer 1

Допустим, каждый человек в команде поддерживает свой собственный репозиторий. Один человек в команде поддерживает так называемое хранилище main.

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

Теперь владельцу main нужен как минимум доступ на чтение для каждого репозитория участников. Владелец main затем извлекает из каждого хранилища по очереди. Если нет конфликтов слияния, нет проблем. Если является конфликтом, то владелец main прерывает коммит, и пусть тот, кто владеет кодом, исправит конфликт. Давайте рассмотрим эту часть подробно

1. main тянет с bob - ок; объединение завершено и опубликовано
2. main тянет от tom - конфликт; слияние отменено
3. владелец main говорит tom, чтобы вытащить последние изменения и исправить конфликт
4. tom может исправить конфликт сам, затем скажите main, чтобы повторить попытку
5. main тянет с tom - ок

Этот процесс просто повторяется каждый день или, как часто, ваш цикл интеграции.

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

Answer 2

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

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

Когда у нас была распределенная разработка, мы использовали вики-страницу с таблицей, в верхней части которой находится человек с «токеном».

Answer 3

Это похоже на работу для git rebase.

Workflow

Вы работаете над отдельной веткой (назовем это local), и вы делаете несколько коммитов. Когда вы будете готовы внести изменения, извлеките ветку master и выполните команду git pull. Оформите вашу ветку local и сделайте git rebase master. Эта команда будет:

1. отложите ваши изменения / коммиты (на local), так как master и local разошлись,
2. выполнить ускоренное слияние с веткой master,
3. подтвердить ваши первоначальные изменения в локальной ветке. Помните, что сообщение, автор и дата фиксации остаются неизменными: НО хеш коммита ИЗМЕНЕНИЯ . Это происходит потому, что все объекты (коммиты, деревья, BLOB-объекты) являются неизменяемыми, и поскольку родительское свойство коммита изменяется, git создаст еще один коммит.

Последствия git rebase

Так как хеш коммита изменяется, вам нужно выполнять перебазирование только в МЕСТНЫХ ветвях (т. Е. НЕ отправлено на удаленный доступ).

Answer 4

Я наконец понял, что именно имел в виду, и решение состоит в том, чтобы просто перебазировать коммит слияния, как описано здесь: Перебазировать коммит слияния Git