摆脱git不需要的合并分支? [英] Get rid of git unneeded merged branch?

问题描述

我制作了一个分支(folders)，该分支经过故意试验，在其上进行填充，最终喜欢它，以交互方式重新进行基础处理以减少提交次数，并重新进行基础处理或挑选到master中.我删除了分支名称，并等待该分支"上的提交自行死亡.

I made a branch (folders) that was deliberately experimental, did stuff on it, eventually liked it, rebased interactively to reduce the number of commits, and rebased or cherry-picked into master. I deleted the branch-name and waited for the commits on that "branch" to die of their own accord.

但是由于某种原因，无名的分支"自身合并到了master中.我不知道那是怎么回事.我认为这与推拉有关.

But then for some reason the nameless "branch" got itself merged into master. I have no idea how that happened; I think it had something to do with pushing and pulling.

所以现在我有了这两个无关的提交，如Sourcetree的屏幕截图所示(它们是右侧轨道上的红色提交):

So now I've got these two extraneous commits, as shown in this screenshot from Sourcetree (they are the red commits on the right-hand track):

它们确实是无关紧要的；红色提交(be937ba和33b3b01)的操作与重新定位底部的第一个提交(4fc6b63)完全相同，因为后者是从前者中压榨出来的.

And they really are extraneous; what the red commits do (be937ba and 33b3b01) is exactly the same as what the first commit at the bottom of the rebase does (4fc6b63), because the latter is squashed from the former.

出于完整性考虑，这是reflog的相关部分:

For the sake of completeness, here's the relevant part of the 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).我是唯一的消费者，所以这很安全.我在多台计算机上使用了此存储库，但很高兴删除另一台计算机上的工作文件夹并重新克隆.

I'd like to get rid of 33b3b01 (HEAD@{44}) and be937ba (HEAD@{45}) and force that change up to the remote (github). I am the only consumer so this is safe; I use this repo on multiple machines but I'm happy to delete the work folder on the other machine and clone afresh.

所以问题是，我可以这样做吗?这样做安全吗?我该怎么做?

So the question is, can I do that, is it safe to do, and how do I do it?

补充问题是，这是怎么发生的?我认为"this"的意思是，HEAD@{27}如何成为合并提交?我以为我有了这个狡猾计划"，将一个临时分支用作一个实验性世界，并使其提交死亡，所以它以某种方式出错了.我知道我没有故意合并，但是pull当然会合并，所以这可能就是答案.

Supplementary question is, how did this happen? I think what I mean by "this" is, how did HEAD@{27} become a merge commit? I thought I had this Cunning Plan to use a temporary branch as an experimental world and let its commits die, and it went wrong somehow. I know for a fact that I didn't deliberately merge, but of course pull does merge so that's probably the answer.

编辑，这是来自git log -g的更完整打印输出的更多信息，显示了图形中意外合并的部分.

EDIT Here's more info from a fuller printout of git log -g, showing the part of the graph where the unintended merge happened.

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进行合并；我没有明显的办法，因为它没有分支名称(我已经删除了名称).

The mystery is how "chugging some more" became a merge commit (Merge: 6a0d405 33b3b01). I think it has something to do with pushing, pulling on another machine, and pushing there. But I assure you I never specifically asked 33b3b01 to be merged; there's no obvious way I could, as it had no branch name (I had deleted the name).

推荐答案

答案是:

• 步骤1.git replace --edit 1d2b83f

步骤2.在编辑器中打开提交的文本描述.它有两条parent行.删除您不喜欢的parent行；在这种情况下，就是具有父33b3b01...的那个.保存并退出编辑器.

Step 2. A textual description of the commit opens in the editor. It has two parent lines. Delete the parent line you don't like; in this case, that's the one with the parent 33b3b01.... Save and exit the editor.

不想要的承诺消失在一团烟雾中.历史现在是一条直线.如果您执行git log --pretty=raw并进行遍历，则可以看到历史现在是从一次提交到下一次提交(即上一次提交)的一条直线.

The unwanted commits have vanished in a puff of smoke. The history is now a single straight line. If you do a git log --pretty=raw and walk through it, you can see that the history is now a single straight line from one commit to the next (meaning the previous one).

第3步.git filter-branch-这(感谢@torek)将替换内容写入实际的历史记录中，以便该存储库的克隆版本可以看到我所看到的内容.

Step 3. git filter-branch — This (thanks, @torek) writes the replacement into the actual history, so that clones of this repo will see what I'm seeing.

然后我删除了遥控器，并创建了一个新的遥控器并推送到它，只是为了确保我们的上游是干净的.

I then deleted the remote and create a new remote and pushed to it, just to make sure we have a clean upstream.

这是一个简单的案例，因为没有其他历史可以重写，没有其他人共享工作，没有其他分支，等等，并且因为我尝试的不需要的分支没有任何东西摆脱.我试图简化发生的事，而不是更改发生的事.

This was an easy case because there was no other history to rewrite, and because no one else was sharing the work, there were no other branches, etc., and because there was nothing coming from the unwanted branch that I was trying to get rid of. I was trying to simplify the story of what happened, not to change what did happen.

这篇关于摆脱git不需要的合并分支?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！