Избавиться от git ненужной объединенной ветки?

Question

Я сделал ветку (folders), которая была нарочито экспериментальной, сделал что-то на ней, в конечном итоге понравился, сделал интерактивную перебазировку, чтобы уменьшить количество коммитов, и перебазировал или выбрал вишню в master. Я удалил имя ветки и дождался коммитов на этой "ветке" до d ie по собственному желанию.

Но затем по какой-то причине безымянная "ветка" сама слилась в master. Я понятия не имею, как это произошло; Я думаю, что это как-то связано с толканием и вытягиванием.

Так что теперь у меня есть эти два посторонних коммита, как показано на этом скриншоте из Sourcetree (это красные коммиты на правой дорожке):

И они действительно посторонние; то, что делают красные коммиты (be937ba и 33b3b01), в точности совпадает с тем, что делает первый коммит в нижней части ребазы (4fc6b63), потому что последний компенсируется первым.

Ради полноты вот соответствующая часть reflog:

6464656 HEAD@{24}: commit: finished splitters, about to reorg again
a1fc825 HEAD@{25}: commit: finished writing switch, renamed splitter partitioners
d822ddc HEAD@{26}: pull --no-commit origin master: Fast-forward
1d2b83f HEAD@{27}: commit (merge): chugging some more
6a0d405 HEAD@{28}: rebase -i (finish): returning to refs/heads/master
6a0d405 HEAD@{29}: rebase -i (pick): a bunch more pages
0b4f305 HEAD@{30}: rebase -i (pick): chugging along once again
bd9aa4f HEAD@{31}: rebase -i (pick): okay reorg into folders, looks okay to me
1a80352 HEAD@{32}: rebase -i (pick): wrote a bunch more pages
4fc6b63 HEAD@{33}: rebase -i (squash): revise nextprevs and breadcrumbs so we use folders but maintain just one nextprevs organized hierarchically
be937ba HEAD@{34}: rebase -i (start): checkout 28c6f1c81b36790b212727adaf209f30c0c0a031
a8f44e6 HEAD@{35}: rebase finished: returning to refs/heads/master
a8f44e6 HEAD@{36}: rebase: a bunch more pages
e6468f0 HEAD@{37}: rebase: chugging along once again
5c32d8e HEAD@{38}: rebase: okay reorg into folders, looks okay to me
d323c8c HEAD@{39}: rebase: wrote a bunch more pages
33b3b01 HEAD@{40}: rebase: checkout folders
9937608 HEAD@{41}: checkout: moving from folders to master
33b3b01 HEAD@{42}: reset: moving to 33b3b01717af3845160ce5b576099264b538a016
db95dc0 HEAD@{43}: merge master: Merge made by the 'recursive' strategy.
33b3b01 HEAD@{44}: commit: fix atrocious previous implementation
be937ba HEAD@{45}: checkout: moving from master to folders
9937608 HEAD@{46}: rebase -i (finish): returning to refs/heads/master
9937608 HEAD@{47}: rebase -i (pick): a bunch more pages
f6e20ea HEAD@{48}: rebase -i (pick): chugging along once again
debb94b HEAD@{49}: rebase -i (pick): okay reorg into folders, looks okay to me
08b072e HEAD@{50}: rebase -i (pick): wrote a bunch more pages
be937ba HEAD@{51}: rebase -i (squash): revise nextprevs and breadcrumbs so we use folders but maintain just one nextprevs organized hierarchically
092014e HEAD@{52}: rebase -i (start): checkout 28c6f1c81b36790b212727adaf209f30c0c0a031
fbf96a0 HEAD@{53}: reset: moving to HEAD
fbf96a0 HEAD@{54}: commit: a bunch more pages
52f19d0 HEAD@{55}: commit: chugging along once again
3251531 HEAD@{56}: commit: okay reorg into folders, looks okay to me
0a8a991 HEAD@{57}: commit: wrote a bunch more pages
54fa472 HEAD@{58}: commit: modified breadcrumbs to go with modification of nextprevs of previous commit
092014e HEAD@{59}: commit: experiment: can we use folders but maintain just one nextprevs organized hierarchically
28c6f1c HEAD@{60}: commit: tweaks to css for iPhone

Я бы хотел избавиться от 33b3b01 (HEAD@{44}) и be937ba (HEAD@{45}) и принудительно перейти на удаленный (github) , Я единственный потребитель, так что это безопасно; Я использую этот репозиторий на нескольких компьютерах, но я счастлив удалить рабочую папку на другом компьютере и клонировать заново sh.

Итак, вопрос в том, могу ли я это сделать, безопасно ли это делать, и как мне это сделать?

Дополнительный вопрос: как это произошло? Я думаю, что я подразумеваю под «этим», как HEAD@{27} стал коммитом слияния? Я думал, что у меня есть этот хитрый план, чтобы использовать временную ветвь в качестве экспериментального мира и позволить ее совершать d ie, и это почему-то пошло не так. Я точно знаю, что я сознательно не сливался, но, конечно, pull сливается, так что это, вероятно, ответ.

РЕДАКТИРОВАТЬ Вот дополнительная информация из более полной распечатки git log -g, показывающей часть графика, где произошло непреднамеренное слияние.

commit 6464656c1de2f127ae38836bc834382477beda9e
Reflog: HEAD@{24} Reflog message: commit: finished splitters, about to reorg again

    finished splitters, about to reorg again

commit a1fc8250746a5fce6b66272e4ac11bb1f337d29c
Reflog: HEAD@{25} 
Reflog message: commit: finished writing switch, renamed splitter partitioners

    finished writing switch, renamed splitter partitioners

commit d822ddc6372bb92d50155de83b8f570b52e8cc73
Reflog: HEAD@{26} 
Reflog message: pull --no-commit origin master: Fast-forward

    starting to write switchToLatest

commit 1d2b83f0f024ae8efdd9c4a90a99353b502ad532
Reflog: HEAD@{27} 
Reflog message: commit (merge): chugging some more
Merge: 6a0d405 33b3b01

    chugging some more

commit 6a0d405394fc7a172e4987bd785ad8d8d7fb7d5b
Reflog: HEAD@{28}
Reflog message: rebase -i (finish): returning to refs/heads/master

    a bunch more pages

commit 6a0d405394fc7a172e4987bd785ad8d8d7fb7d5b
Reflog: HEAD@{29} 
Reflog message: rebase -i (pick): a bunch more pages

    a bunch more pages

Загадка в том, как «еще немного» - коммит слияния (Merge: 6a0d405 33b3b01). Я думаю, что это как-то связано с нажатием, вытягиванием другой машины и нажатием там. Но, уверяю вас, я никогда специально не просил объединить 33b3b01; нет очевидного способа, которым я мог бы, поскольку у него не было имени ветви (я удалил имя).

Answer 1

Ответ таков:

• Шаг 1. git replace --edit 1d2b83f

• Шаг 2. Текстовое описание коммита открывается в редактор. У него две parent строки. Удалите строку parent, которая вам не нравится; в данном случае это родитель с 33b3b01.... Сохраните и выйдите из редактора.

  Нежелательные коммиты исчезли в облаке дыма. История теперь представляет собой одну прямую линию. Если вы выполните git log --pretty=raw и пройдете по нему, вы увидите, что история теперь представляет собой одну прямую линию от одного коммита к следующему (имеется в виду предыдущий).

• Шаг 3. git filter-branch - Это (спасибо, @torek) записывает замену в реальную историю, так что клоны этого репо увидят то, что я вижу.

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

Это был простой случай, потому что не было никакой другой истории, которую нужно переписать, и потому что никто больше не разделял работа, других ветвей не было, и т. д. c., и потому что от нежелательной ветви, от которой я пытался избавиться, не было ничего. Я пытался упростить историю того, что произошло, а не изменить то, что произошло .

Answer 2

Я просто вручную воссоздаю нужную вам историю через Reset и Cherry-Pick (и, возможно, Rebase), а затем использую git push --force, чтобы переключить ваш пульт в состояние локального репо.

• Оформить master ветвь
• Жесткий сброс локально master до 6a0d405 (фиксация до ошибочного слияния)
• Cherry-выбрать последующие хорошие коммиты.
• В вашей новой ветке не будет плохих коммитов или слияния.
• Force-pu sh ветка для перезаписи неверной версии слияния на сервере.

Я тоже использую SourceTree совсем немного, и все вышеперечисленное, за исключением силы pu sh, можно выполнить с помощью простых команд в пользовательском интерфейсе с помощью мыши. Мне нравится делать это в SourceTree для визуализации во время работы.

Я часто выполняю работу по перестройке в отдельной ветке, чтобы предотвратить случайную потерю какой-либо работы, а затем сбрасываю / pu sh master только в конец.

IMO с использованием общих команд и затем принудительного нажатия кажется на намного проще и менее подвержен ошибкам, чем более эзотерический c маршрут git replace и git filter-branch для перезаписи история.

Answer 3

Вы можете использовать интерактивную перебазировку, с которой вы, кажется, хорошо знакомы.

git rebase -i 638723a

Редактор будет выдавать каждый коммит в строке. Удалите строки с нарушающими коммитами, включая слияние. Затем сохраните и выйдите.

Если вы хотите отменить это, используйте git reset --hard ORIG_HEAD или запомните идентификатор фиксации, в котором находится ваша ветвь перед перебазировкой, и сбросьте его до этого.