Как уменьшить избыточность слияния, которая используется, чтобы убедиться, что master является корнем всего в нашем рабочем процессе Git?

Мы используем рабочий процесс Git от Vincent Driessen, 2 долгоживущие ветки. мастер/разраб. Мы считаем, что нам нужны 2 долгоживущие ветки вместо одной в потоке github, потому что мы работаем на предприятии ( 2Б) бизнес. Наш клиент предпочитает стабильный продукт нашим новейшим функциям.

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

Но вдруг команда поддержки клиентов получает гневный звонок от клиента и говорит нам, что нам нужно конкретное исправление ошибки/функция, чтобы продукт был быстро добавлен. Эта ситуация прерывает наш обычный рабочий процесс и вводит вопрос, который я задаю.

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

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

Я знаю, что могу перебазировать ветку dev на master, чтобы избежать этого слияния. Но rebase также не идеален по нескольким причинам (я не перечислил их здесь, чтобы не уводить свой вопрос в сторону)

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


git merge git-merge git-workflow cherry-pick
person Qiulang    schedule 09.12.2020    source источник
comment
Ваш точный рабочий процесс мне не совсем понятен, но я могу предложить создать ветки исправлений от master, где вы исправляете ошибки, а затем сливаетесь обратно с веткой master.   -  person Tim Biegeleisen    schedule 09.12.2020
comment
Нет, это то, что я сказал в своем вопросе, я не могу этого сделать. Я не могу создать ветку исправления ошибок и использовать ее в качестве базы слияния, потому что код, который мне нужен, УЖЕ находится в ветке разработки.   -  person Qiulang    schedule 09.12.2020
comment
Затем исправьте свой рабочий процесс, чтобы этого не произошло. Это мой ответ.   -  person Tim Biegeleisen    schedule 09.12.2020
comment
Но как и это мой вопрос. Я считаю, что всегда возможно, что нужная ветка мастера кода уже находится в будущей ветке.   -  person Qiulang    schedule 09.12.2020
comment
Вы уже однажды объединили ветку feature с master, а теперь исправляете ошибку в feature, и вопрос в том, как вернуть эту фиксацию исправления обратно в master?   -  person Tim Biegeleisen    schedule 09.12.2020
comment
Правильно, и мне также нужно показать мастеру, это корень! Это сложная часть и мой вопрос.   -  person Qiulang    schedule 09.12.2020
comment
В этом случае вам следует выбирать вишни, но лучшим долгосрочным решением будет исправление ошибок в master, а затем перебазирование веток функций/выпусков на master, чтобы получить последние исправления ошибок. Этот подход оставляет master источником истины для других ветвей, а это именно то, что вам действительно нужно.   -  person Tim Biegeleisen    schedule 09.12.2020
comment
Конечно, я это знаю. Но реальность такова, что наша тестовая команда определит пару ошибок, которые нам нужно исправить, и мы исправим их в ветке разработки, и вдруг служба поддержки клиентов скажет нам, что нам нужно как можно скорее исправить конкретную ошибку в продукте. Отсюда и проблема.   -  person Qiulang    schedule 09.12.2020
comment
Пожалуйста, перечитайте комментарий выше :-)   -  person Tim Biegeleisen    schedule 09.12.2020
comment
Я сделал, но то, что я сказал вам, является реальностью, и мой вопрос остается нерешенным, т.е. возможно ли избежать дублированного слияния? Кажется, нет.   -  person Qiulang    schedule 09.12.2020
comment
Вы сказали в комментарии, что не можете создать ветку исправления ошибок, потому что исправление уже находится в ветке разработки. Можете ли вы объяснить свои рассуждения здесь? Я бы создал ветку от мастера, вишневый выбор коммитов разработчиков в ветку исправления ошибок, а затем объединил бы это с мастером обычным способом (например, через запрос на включение). Другими словами, я не вижу проблемы в том, что исправление находится в ветке dev дополнительно — когда вы объединяете это с мастером, дублирующий коммит будет автоматически пропущен, так как мастер предположительно будет иметь его на тот момент.   -  person halfer    schedule 09.12.2020
comment
Это не я не могу, но бесполезно. Согласно вашему методу, при слиянии ветки исправления ошибок с мастером обычно происходит ускоренная перемотка вперед. Чем это отличается от вишневого выбора непосредственно в master? И мой вопрос остается, т.е. Мне нужно показать, что мастер является корнем всей ветки, поэтому теперь мне нужно дополнительное дублированное слияние в dev. Это слияние я не хочу.   -  person Qiulang    schedule 09.12.2020
comment
Я голосую за то, чтобы закрыть это, так как нужно сосредоточиться, потому что смещение ворот доходит до противоречивых утверждений.   -  person jthill    schedule 10.12.2020
comment
Скажите, пожалуйста, где вы видите «самопротиворечивые утверждения, я просто удалю свой вопрос позже».   -  person Qiulang    schedule 10.12.2020
comment
@jthill Я не могу удалить свой вопрос, потому что вы ответили на него. Поэтому я переписал его, пожалуйста, дайте мне знать, если в нем все еще есть противоречивые утверждения?   -  person Qiulang    schedule 10.12.2020
comment
@TimBiegeleisen Я получил 2 голоса, чтобы закрыть свой вопрос, поэтому я переписал его. Можете ли вы взглянуть, чтобы убедиться, что она более четкая, чем вчерашняя версия? Спасибо   -  person Qiulang    schedule 10.12.2020
comment
git merge -s ours bugfix26535 добавит пустую фиксацию в dev. И это проблема, которую я хочу решить в первую очередь! из комментариев к моему ответу, но (а) вы говорите в вопросе, что вводите пустые коммиты в качестве стандартной практики, и (б) до этого они не вызывались какой-либо проблемой. Это только для начала.   -  person jthill    schedule 10.12.2020
comment
@jthill Итак, я считаю, что моя вторая версия исправила это.   -  person Qiulang    schedule 10.12.2020
comment
после этого мы всегда делаем слияние из ветки master в ветку dev. Слияние обычно не вносит изменений в код в ветке разработки. Я считаю, что вы не имеете никакого смысла вообще.   -  person jthill    schedule 10.12.2020
comment
Вы имеете в виду, что слияние не нужно?   -  person Qiulang    schedule 10.12.2020

Ответы (1)


arrow_upward
0
arrow_downward

Полноценный (осмелюсь сказать, канонический) способ мучительно-и-иногда-приятно-правильно применять фиксацию между ветками:

git checkout -b fixbug26535 $(git merge-base all active tips with the bug)
git cherry-pick the bug fix
git checkout where-the-fix-came-from
git merge -s ours bugfix26535

(Поэтому, если у вас есть master, dev1 и dev2, а исправление удобно находится на подсказке dev1,

git checkout -b fixbug26535 $(git merge-base master dev1 dev2)
git cherry-pick dev1
git checkout dev1
git merge -s ours bugfix26535

)

и теперь у вас есть хорошая объединяемая ветка исправления ошибок, которая не будет нести нежелательные изменения или создавать ненужные конфликты ни в одном из советов, с которыми она может быть объединена. Вы можете объединить это с master и dev2 на досуге.

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

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

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

person jthill    schedule 09.12.2020
comment
Я обновляю свой вопрос о том, почему моя проблема возникла в первую очередь, и я чувствую, что это довольно распространено (по крайней мере, это то, что я нахожу) - person Qiulang; 09.12.2020
comment
Это то, к чему относится этот ответ, исправление, которое вам нужно выбрать из более длинной ветки. - person jthill; 09.12.2020
comment
Я не знаком с тем, что вы сказали, поэтому мне нужно сначала изучить это. Спасибо. Кстати, часть причины, по которой я обновляю свой вопрос, заключается в том, что я чувствую, что это не моя уникальная проблема, я также не понимаю, почему мой вопрос получил закрытое голосование. - person Qiulang; 09.12.2020
comment
Я думал о вашем решении и пришел к выводу, что оно не сработает! git merge -s ours bugfix26535 добавит пустую фиксацию в dev. И это проблема, которую я хочу решить в первую очередь! - person Qiulang; 10.12.2020
comment
Кроме того, ваш первый шаг git checkout -b fixbug26535 $(git merge-base all active tip with the bug) в моем случае бесполезен. Поскольку мы очень старались сделать master корнем всех веток (и это вызывает мою проблему), результатом этого будет ветка, просто дублирующая ветку master. - person Qiulang; 10.12.2020