Облажался мастер ветку git... Не могу понять, что мне нужно вернуть

Question

Я работаю над git-репозиторием, в котором есть ветка master, мы назовем его ab ветка. Моя команда работает над ab ветвь и имеет рабочий процесс pull-запроса с использованием github. Один из моих товарищей по команде сделал запрос на удаление из своего филиала jeremy_ab_deletions к ab ветка. Я проверял / проверял его изменения, но когда я пошел, чтобы объединить их в ab Я случайно слил их с мастером вместо этого и подтолкнул мастера к github, прежде чем поймал свою ошибку. Думая, что я мог бы просто сделать мерзавец git revert SHA и, казалось, сработало...

Я подумал, что этого было достаточно, и я с радостью вернулся в свою ветвь и продолжил работать. Теперь, однако, я понимаю, что предыдущие коммиты из ab ветвь, которая никогда не должна заканчиваться мастером, все в мастере. Это... довольно беспорядок. Так как его ветвь была первоначально отделена от ab, а затем я слил его в мастер, я должен был вернуться, используя git revert -m 1 SHA,

Сегодня я пытался выяснить, где именно я ошибся, и я запутался, основываясь на истории мерзавцев и моих рефлогах. Сначала я попытался отменить возврат, а затем делать git revert -m 1 SHA Но мерзавец говорит мне:

fatal: Mainline was specified but commit 4c431c345dfe0a856967c090932c32f153824085 is not a merge.

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

This was supposed to be on AB... 
…
d985b5bcf8 Browse code
Nathan B authored 8 days ago

This was supposed to be on AB... 
…
0e01911273 Browse code
Nathan B authored 8 days ago

removed unecessary tests
4c431c345d Browse code
Nathan B authored 8 days ago
Apr 17, 2012

removing un-used views and pages
a546f90ed3 Browse code
jeremychurch authored 10 days ago

Два коммита, которые говорят, что "это должно было быть на AB", - это возвратные коммиты для возврата "удаленных ненужных тестов" и "удаления неиспользуемых представлений и коммитов страниц". Следующий коммит был совершен сегодня, а коммит до этого был 16-го, ни один из которых не был связан. Я не вижу, где произошло фактическое слияние.

Я просмотрел свой журнал, чтобы увидеть, где именно все испортилось. Я пошел вверх и вниз версии рефлога, используя git reset --hard HEAD@{NUM} и затем проверяет ключевые файлы, чтобы увидеть, были ли плохие изменения в этом месте. Наконец я сузил это до этих reflogs:

1fe2be2 HEAD@{79}: checkout: moving from 1fe2be29c6eda9f9fc9eb0b372ee83b7c15dfc2c to jeremy_ab_deletions
1fe2be2 HEAD@{80}: HEAD@{3}: updating HEAD
4c431c3 HEAD@{81}: HEAD@{1}: updating HEAD
47a97af HEAD@{82}: commit: removed unecessary tests, routes, and controller actions
4c431c3 HEAD@{83}: merge jeremy_ab_deletions: Fast-forward
1fe2be2 HEAD@{84}: checkout: moving from master to ab
d985b5b HEAD@{85}: revert: This was supposed to be on AB...
0e01911 HEAD@{86}: revert: This was supposed to be on AB...
4c431c3 HEAD@{87}: merge jeremy_ab_deletions: Fast-forward
c121a08 HEAD@{88}: checkout: moving from jeremy_ab_deletions to master
4c431c3 HEAD@{89}: commit: removed unecessary tests
a546f90 HEAD@{90}: checkout: moving from ab_page_changes to jeremy_ab_deletions
511b340 HEAD@{91}: checkout: moving from jeremy_ab_deletions to ab_page_changes
a546f90 HEAD@{92}: pull [e-mail]:REDACTED/repo.git ab-remove-stuff: Fast-forward

В частности, в HEAD@{88} нет плохих коммитов, а в HEAD@{87}. Поэтому разумно предположить, что я облажался на merge jeremy_ab_deletions: Fast-forward коммит...... но я не могу понять, какой "коммит коммит" это будет. Я попробовал это:

$ git revert -m 1 4c431c3
fatal: Mainline was specified but commit 4c431c345dfe0a856967c090932c32f153824085 is not a merge.

Кажется, я... не могу найти фактический коммит слияния? Кто-нибудь знает, что я сделал не так:/ Я потерял все виды прямо сейчас.

Answer 1

Если бы никто не вытащил этого мастера (или вытащил, но наверняка не использовал его), я бы сделал следующее:

1. Если после "аварии" не было выполнено никакой работы над мастером, я просто сбросил бы ее до последнего удачного коммита, а затем обновил бы удаленную ветку "Мастер" (нажав -f).
2. Если какая-то работа была проделана, вы можете сбросить ее до последней удачной фиксации, а затем использовать git rebase -i и удалите проблемные коммиты, оставив хорошие в списке. Затем снова вам нужно нажать (с -f).

Кроме того, вы можете сделать все это в новой ветке:

1. Оформить последний хороший коммит в master, создать там ветку,
2. Тогда используйте git rebase -i master отфильтровывать плохие коммиты.
3. Затем вы можете вернуться к мастеру и "объединить" вручную, внося все изменения из новой ветви и перезаписывая все в мастере (вы можете использовать --no-commit а также git checkout --theirs)
4. толкать (без -f) фиксированный мастер.

Надеюсь это поможет! Я ненавижу мергентства.

Answer 2

ОБНОВЛЕНИЕ: В то время как это может помочь кому-то еще, это фактически сделало вещи более расстраивающими для меня. Я оставлю это здесь на случай, если кто-то еще наткнется на это.

Синелав указал мне правильное направление... но я нашел более подходящий ответ: вернуться к коммиту с помощью хеша SHA в Git?

Ответное сообщение гласит:

Если вы хотите зафиксировать поверх текущего HEAD с точным состоянием при другом коммите, отменяя все промежуточные коммиты, то вы можете использовать reset, чтобы создать правильное состояние индекса для фиксации.

Это именно то, что я хотел. Я хочу вернуться к HEAD@{88}, но сделать так, чтобы он возвращал свой коммит, так как некоторые люди уже извлекли основную ветвь, и я не хочу заставлять их проходить через шаги сброса, как я должен был... Так что это команды, которые я использовал:

# reset the index to the desired tree
git reset HEAD@{88}

# move the branch pointer back to the previous HEAD
git reset --soft HEAD@{1}

git commit -m "Revert the bad ab merge"

# Update working copy to reflect the new commit
git reset --hard

# Clean untracked files
git clean -f -d

Глядя на историю, я вижу, что я только что создал коммит с точным аннулированием всех изменений, которые должны были быть эксклюзивными для ветки ab.

(обновление): Неважно, это не совсем то, что я хотел. В нашем репо есть несколько веток, а также ветка master. Мастер предназначен для хранения изменений, которые являются универсальными среди других трех ветвей, и он часто объединяется в эти ветви. Выполнение этой серии команд revert-with-a-commit сделало слияние master с веткой 'ab' (или любой другой ветки в этом отношении) серьезным кошмаром конфликтов слияния и непреднамеренных удаленных файлов (так как они должны жить в ab Просто не в мастер). Я использовал вышеизложенное решение Sinelaw и работал с одним нетехническим дизайнером, который также подтолкнул мастера вернуться к хорошей версии.