所以我fork，然后分支，并提交代码。现在我有15份工作提交，我需要压缩成一份。
首先，我将合并上游代码。
git fetch upstream master
git merge upstream/master master
然后我尝试在我所在的分支上进行最后15次提交（不在主人身上）
git rebase -i HEAD~15
现在我有数百个提交显示与我的分支完全无关。所有在线教程都非常基础，我认为它应该在分叉工作流程中略有不同。
我错过了什么？
答案 0 :(得分：1)
我认为您希望{em>进入目标分支的路上squash，而不是 in （通常）。因此，如果你有一个变化的分支，并希望将它们压缩成主，那么根据你的工作流程，有几个选项。
<强> CLI
# while on master
$ git merge my-feature-branch --squash
<强> Github上
在Github中，您可以选择在合并PR时压缩合并 https://github.com/blog/2141-squash-your-commits
Bitbucket / Stash
他们会自动为您执行此操作。
答案 1 :(得分：0)
如果您在rebase下的提交子集中进行合并，并且您没有，那么git rebase -i的行为会有所不同。在您的情况下，您首先合并，然后您想要对包含合并的提交子集进行重新定义。
通常，我会避免重新设置合并提交以保持简单。
正如@thescientist所说，在你的情况下，最好在合并时压缩提交 ，而不是在合并之后。
可能有用的一句话：
通常，当您在线性历史记录上调用git rebase -i时，您会看到提交列表，并且您不会更改任何内容（只保留pick），不会执行任何操作，也不会有历史记录被重写
但是，如果您发现自己意外地在提交的过大子集上运行git rebase -i，这涉及到合并提交，您将经常看到大量提交，如果您不更改任何内容（保持{ {1}}），git将开始重写那些提交，这通常不是你想要的。
要摆脱这种情况，删除所有行;通常当在rebase期间删除某些行时，git会删除与这些行相对应的提交，但如果删除所有行，git将不执行任何操作 - 这是一种有用的方法，当你搞砸某事时中止 - 因为如果你想删除所有提交，你可以使用pick。