Повторите отмененное слияние git

#git

Вопрос:

У меня есть ветвь под названием dev и ответвление темы от нее под названием feature-1. После тестирования я хочу объединить функцию-1 в dev. Но сначала в dev были внесены изменения, пока я работал над функцией-1, поэтому я решил объединить их:

 git checkout feature-1
git merge dev
 

Работал нормально, но затем, не осознавая этого, я случайно удалил новые файлы и отменил удаление файлов, которое произошло в dev. Я подумал: «Как бы то ни было, я зафиксирую и снова объединюсь позже».

 git add new-files
git rm old-files
git commit -m "broke merge"
 

Но потом я не смог снова слиться:

 git merge dev
>>>>> Already up to date
 

Но…есть различия в файлах между этими ветвями! Если я объединю функцию-1 в dev, не будет ли она воспроизводить эти фиксации удаления поверх dev?

Я попытался вернуть слияние:

 git revert -m 1 *merge-hash*
 

Но мерзавец все еще думает, что один из них является родителем другого или что-то в этом роде. Повторное слияние по-прежнему не удается»уже обновлено».

После этого я также попытался перенастроить dev на функцию-1, но я все еще не вижу изменений от dev, и к этому моменту я заблудился.

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

ИЗМЕНИТЬ: Я попытался вернуть свой возврат по предложению Лайнуса, которое я прочитал здесь

 git revert *revert-hash*
 

Теперь я вижу все изменения от дэва (Я ДУМАЮ). Из журнала git не очевидно, какие фиксации произошли в каком порядке сейчас.

ПРАВКА 2: Затем я запустил статус git и нашел

На функции ветви-1 Ваша ветвь и «источник/функция-1» разошлись, и у каждого из них 5 и 3 разных коммита соответственно. (используйте «git pull», чтобы объединить удаленную ветвь с вашей)

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

Комментарии:

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

2. Поскольку вам не нравится то, что вы сделали с feature1, начиная с обратного слияния, почему бы просто не сбросить жесткий режим до того, как вы сделали эти плохие вещи?

3. После удаления объединенных файлов из ветви разработки, как я могу «воспроизвести коммиты разработчика», чтобы вернуть их обратно?

4. Ты все время говоришь «повтор». Я не думаю, что это слово означает то, что вы думаете.

5. Проблема началась, когда вы сказали git checkout feature-1 и git merge dev . Ты был на каком-то обязательстве, когда сказал это. Так git reset --hard thatCommit что и все будет так, как было до того, как ты это сказал. Все это было просто сном. 🙂

Ответ №1:

Когда это происходит со мной, во многих случаях самым простым решением является создание новой ветви из dev, и git cherry-pick ваши изменения из feature-1 фиксируются в одно время. Таким образом, вы получите именно то, что хотите, вместо того, чтобы пытаться исправить сломанную историю, которая в любом случае будет выглядеть уродливо.

Другое решение-перебазироваться в нужную ветвь и очистить ее от фиксаций

В функции-1 запуск ветви rebase dev -i . Затем удалите фиксации, которые вы не хотите, pick заменив d их .

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

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

Если вы решите проблему локально с помощью rebase -i , git не позволит вам нажимать, так как вы изменили историю. Вы можете решить эту проблему с помощью принудительного нажатия, чтобы происхождение соответствовало вашему местному: git push --force-with-lease . Сила нажатия требуется всякий раз, когда вы перебазируете-i, так как вы меняете историю.

Комментарии:

1. Эта интерактивная перебазировка очень аккуратна! Возможно, это решило бы мою проблему, если бы я также не отправил это неудачное слияние на пульт дистанционного управления. В нынешнем feature-1 виде и origin/feature-1 разошлись, и это не помогает в этом.

2. Если вы решите проблему локально, вы можете принудительно нажать, чтобы источник соответствовал вашему локальному: git push --force-with-lease . Это заставит remote принять ваши изменения. Сила нажатия требуется всякий rebase -i раз, когда вы меняете историю.