Git revert merge plus one commit on top для повторного слияния

Question

Я сделал огромное слияние с идеей (intellij idea), поэтому, когда все conflicsts были разрешены, и som-код был изменен, и я выполнил (слияние) , то заметили, что есть два файла, которые нужно переделать. Поэтому я снова сделал.

Есть два questionss:

1. Почему я второй фиксации. Это потому, что IDE каким-то образом пропустила added commit to merge (ide not smart enought, чтобы увидеть, что все эти изменения в контексте одного слияния?). Это то, что произойдет, если я забыл add файл в index, если я пойду с командной строкой после слияния (?)

2. Как я мог вернуть эти двух коммитов, так что я мог бы сделать одно чистое слияние?

Как картинке:

[commit1] < - [Мегре фиксации] < - [перед тем фиксации] | (Мастер)

Я попытался git rebase -i rebase HEAD~2 (только первая идея объединить два коммиты), но показал все эти 121 commists - один commit1 и 120 от слияния фиксации.

В принципе, я хочу добавить «потерянный»/«отдельный» [commit1] в [merge-commit] и иметь одно слияние.

ОБНОВЛЕНИЕ: У меня нет моего кода, чтобы попробовать, но имеет ли это смысл?

// revert two commits to have one 
1. git reset --soft HEAD~ 
2. git revert -m 1 merge-commit 
3. git commit 

Ожидаю, что снова увижу изменения, все эти 1 + 120 коммитов. Но как бы я сливаю

// move my merged stuff into new branch 
4. git push origin -u new_branch 

// move back on history in master branch 
5. git reset --hard before-commit 
6. git merge new_branch 
7. git push -f origin master 

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

?

Answer 1

У вас есть много вопросов в одном сообщении.

Почему вы закончили вторую фиксацию? Скорее всего, из-за причуд плагина GIT IntelliJ. Это не делает хорошего различия между промежуточной и рабочей областями, что может привести к таким случаям, как ваш, если вы отредактируете объединенный файл после разрешения. Ничего опасного там, просто дополнительная забота, прежде чем подталкивать ваши изменения вверх по течению. По-прежнему гораздо удобнее разрешать конфликты с IDE, если они не очень тривиальны.

Что касается фиксации, ваша первая попытка сделать интерактивную перезагрузку была в правильном направлении. Я не уверен, что является вторым rebase, о котором вы говорите в своем примере, но git rebase -i HEAD~2 должен был показать вам последние два коммита, где вы могли бы скворовать последний в первый.

Другим вариантом может быть git reset HEAD^ && git commit --amend, который по существу тот же.

Answer 2

Я проверил простой демонстрационный пример.

Так что да, действительно, как работает IDE/IntelliJ Idea - он сливается, но как только вы закончили редактирование в этом инструменте слияния, а затем в главном редакторе кода (еще ничего не запустили), сохраняя код, UI/change-list - он сделает первое коммитирование (само слияние), но некоторые файлы будут оставлены в списке изменений. Итак, вы можете передать их как отдельную фиксацию. (что ват я сделал ..)

Итак, чтобы исправить проблему из командной строки.

Может быть, немного неуклюжий

git reset --soft HEAD~1 // revert left-over commit 
git stash     // safe left-over commit to stas 
git reset --soft HEAD~1 (get back merged content from merge-commit) 

git stash pop   // get stased 


then during conflct accept all from stashed (since we know that those changes were made on top. so noew we have comined content from merge commit and that extra commit) 

git commt -m "merged stuff' // left over of first commit 

Ну тогда имея один совершить .. Я могу объединить его к тому, что я хочу.

Как я мог бы сделать мой «слить», что я должен был, если бы я сделал это правильно:

git checkout newone -b master 
git reset --hard HEAD~1 

git checkout master 
git reset --hard HEAD~1 

git merge newone // accepting all changes