摆脱git不需要的合并分支？

我创建了一个分支（

folders

），它是经过精心实验的，在上面做了一些事情，最终喜欢上了它，以交互方式重新设置了基址以减少提交的数量，然后重新设置基址或将基址选入

master

。我删除了分支名称，并等待“分支”上的提交自动消失

但后来由于某种原因，这个无名的“分支”合并到了

master

。我不知道这是怎么发生的；我认为这与推拉有关

现在我得到了这两个无关的提交，如Sourcetree的屏幕截图所示（它们是右侧轨道上的红色提交）：

它们确实是无关的；红色提交（be937ba和33b3b01）的作用与rebase底部的第一个提交（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）。我是唯一的消费者，所以这是安全的；我在多台机器上使用此repo，但我很乐意删除另一台机器上的工作文件夹并重新克隆

所以问题是，我能这样做吗，这样做安全吗，我怎么做

补充质询是，这是如何发生的？我想我所说的“这”是指，

HEAD@{27}

是如何成为合并提交的？我以为我有一个狡猾的计划，用一个临时分支作为一个实验世界，让它的承诺消失，但不知何故它出了问题。我知道我不是故意合并的，但当然，

pull

确实合并了，所以这可能就是答案

EDIT以下是从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:6A0D40533B3B01

）。我认为这与推动、拉动另一台机器以及推动那里有关。但我向你保证，我从未明确要求合并33b3b01；我没有明显的方法，因为它没有分支名称（我已经删除了名称）。

您可以使用一个您似乎非常熟悉的交互式基础

git rebase -i 638723a

编辑器将在一行中列出每个提交。删除包含违规提交的行，包括合并。然后保存并退出

---

如果要撤消该操作，请使用git reset--hard ORIG_HEAD，或者在重新设置基础之前记住分支所在的提交ID并重置为该ID。

您可以使用交互式重新基础，这一点您似乎非常熟悉

git rebase -i 638723a

编辑器将在一行中列出每个提交。删除包含违规提交的行，包括合并。然后保存并退出

如果要撤消该操作，请使用git reset--hard ORIG_HEAD，或者在重新基址之前记住分支所在的提交ID并重置为该ID。

，答案是：

• 第一步<代码>git替换--编辑1d2b83f

• 第二步。提交的文本描述将在编辑器中打开。它有两行

  parent

  。删除您不喜欢的

  parent

  行；在本例中，这是一个具有父级

  33b3b01…

  。保存并退出编辑器
  不必要的犯罪行为在一股烟雾中消失了。历史现在是一条直线。如果您执行一个git log--pretty=raw并遍历它，您可以看到历史现在是一条从一个提交到下一个提交（意味着上一个提交）的直线

• 第三步

  git filter branch

  -这（谢谢，@torek）将替换写入实际历史记录中，以便此回购的克隆将看到我看到的内容

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

这是一个简单的案例，因为没有其他的历史可以重写，因为没有其他人分享这项工作，没有其他分支，等等，因为没有任何东西来自我试图摆脱的不需要的分支。我试图简化发生的事情，而不是改变发生的事情

答案是：

• 第一步<代码>git替换--编辑1d2b83f

• 第二步。提交的文本描述将在编辑器中打开。它有两行

  parent

  。删除您不喜欢的

  parent

  行；在本例中，这是一个具有父级

  33b3b01…

  。保存并退出编辑器
  不必要的犯罪行为在一股烟雾中消失了。历史现在是一条直线。如果您执行一个git log--pretty=raw并遍历它，您可以看到历史现在是一条从一个提交到下一个提交（意味着上一个提交）的直线

• 第三步

  git filter branch

  -这（谢谢，@torek）将替换写入实际历史记录中，以便此回购的克隆将看到我看到的内容

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

---

这是一个简单的案例，因为没有其他的历史可以重写，因为没有其他人分享这项工作，没有其他分支，等等，因为没有任何东西来自我试图摆脱的不需要的分支。我试图简化发生的事情，而不是改变发生的事情

我只需通过重置和Cherry Pick（可能还有Rebase）手动重新创建您想要的历史记录，然后使用

git push--force

将远程系统更改为本地回购状态

• 签出

  master

  分支
• 硬复位本地

  主机
  至
  6a0d405
  (