Git merge - сквош вызывает головные боли при слиянии ветвей - PullRequest
4 голосов
/ 27 июня 2011

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

Я вытащил некоторые изменения из другого рабочего репозитория.Его изменения в конечном итоге были добавлены и объединены в основную ветку с коммитом сквош.

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

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

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

Ответы [ 2 ]

3 голосов
/ 27 июня 2011

Да, сквош разрушает многократное слияние. Лучший совет - не раздавить - в частности, не раздавливать общедоступные вещи. Перепишите свои собственные коммиты, прежде чем делиться ими с другими, но как только они будут опубликованы, они должны оставаться такими, как есть, с регулярными коммитами слияния.

Вы все еще можете получить разумный вывод журнала, используя git log --first-parent для сжатия журнала объединенной ветви до простого коммита слияния, сохраняя при этом фактическую историю без изменений.

2 голосов
/ 03 августа 2011

Я бы добавил, что сжатие приводит к хаосу только тогда, когда ветки общедоступны, если разработчик работает локально на ветке с грязной фиксацией, такой как «о, буммер, сломал это снова», за которой следует «это работает!»затем «штопать, он снова сломан», затем «ок, исправили это сейчас», их легко раздавить (до того, как они будут отправлены в удаленное хранилище или разделены) в один коммит с хорошим сообщением о том, что изменилось в коде.

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

Мой взгляд на вещи: squash - отличный инструмент для локального рабочего процесса, то есть одного разработчика.как только коммит распределяется, его нельзя раздавить.

...