Копить при слиянии

Question

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

Допустим, у нас есть две ветви A и B. Теперь мы изменим некоторыеfile (foo.c) как в A, так и в B, поэтому мы получаем конфликт слияния при слиянии B с A. Теперь предположим, что какой-то разработчик перепутал и оставил ветвь A в поврежденном состоянии, а ошибка также в foo.c, но в строке, которая не была объединена.

Я вижу некоторые возможности справиться с этой ситуацией:

1. Сохраните ожидающее слияние, исправьте проблему на A, подтвердите и затем примените слияние снова.Однако на данный момент я не уверен, как обращаться с правильной стратегией слияния для изменений, которые оба вносили в foo.c.Разорванная часть может повлиять на некоторые вещи, которые я сделал, и поэтому я не вижу четкого способа разрешения конфликтов.

2. Отмените слияние, исправьте проблему на A, а затемповторить все слияние.Однако я, возможно, уже разрешил другие конфликты, так что это может привести к потере большого количества работы.

3. Возьмите --theirs / - нашу версию файла, выполните слияние,исправить изменения, вишня выбрать изменения, которые были потеряны.Однако тогда у меня будут некоторые изменения дважды.

4. Некоторое другое решение, о котором я не могу думать.

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

Как бы вы справились с такой ситуацией?

Answer 1

Вы не можете спрятать незафиксированное слияние. Вариант 1 немедленно исключается из списка.

С точки зрения чистой истории лучше всего использовать вариант 2. Git обладает способностью запоминать разрешения конфликтов; это просто отключено по умолчанию. Вы можете включить его: git config --global rerere.enabled. Разрешайте конфликты по желанию. Обычно вы выполняете слияние, а Git записывает способ разрешения конфликтов. Поскольку вы на самом деле еще не хотите совершать слияние, вы можете просто запустить git rerere, чтобы немедленно записать разрешения конфликтов без фиксации. (В качестве альтернативы, если вы продолжили и совершили слияние, вы могли бы просто git reset --hard HEAD^, сбросив до него. Разрешение конфликта все равно будет запомнено.)

Затем можно устранить проблему в ветви A и повторить слияние. Git будет re использовать re проводной конфликт re . Он по-прежнему будет помечен как необработанный, так что у вас будет возможность просмотреть его и убедиться, что он все сделал правильно, перед запуском git add по незатронутым путям и совершением слияния.

И мне неясно, какой вариант на самом деле. Зачем тебе вишня? Похоже, что foo.c нарушается только в ветви A, в которую вы сливаетесь, поэтому все это будет в пределах ветви A. Желаемая история - это исправление с последующим слиянием; если вместо этого вы продолжите слияние, а затем исправите проблему, вы просто переключаете порядок двух коммитов. В любом случае, нет необходимости иметь дублирующие коммиты - я могу помочь избежать этого, если вы укажете!