什么可能导致“提前提交的数量”？变基后要改变吗？
在对我几周没有碰过的一个功能分支进行变基之前，它比 master 提前了 25 次提交。变基后，现在有 18 次提交。一路上我必须解决一些冲突。可能正好是 7。
什么可能导致这个数字变化？沿途发现的樱桃选择并变成了 NOOP 提交？上述冲突解决方案？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
有几种可能发生这种情况的方式 - 这不是一个详尽的列表，但应该让您了解这是如何发生的：
1. 精心挑选的提交
首先，您提到来自您的分支的提交已被择优挑选到您要变基的上游分支：只是为了确认这一点，
git rebase将跳过任何此类提交，这可能会导致部分差异。 VonC 对 这个问题。2. 冲突完全解决到上游版本
我最初的怀疑是，当您进行变基并看到冲突时，您总是通过选择上游版本而不是您的更改来解决它们。 （如果这没有敲响警钟，那么我的怀疑可能是完全错误的:)）如果该提交没有引入其他非冲突的更改，那么您的冲突解决方案所做的就是使树相同就像在尝试应用您的更改中的补丁之前一样，因此无需提交任何内容。
不幸的是，当发生这种情况时 git 给你的提示可能相当令人困惑。以下是您将在 git 1.7.1 中看到的示例。首先，提交一个将与尚未从 origin/master 合并的更改发生冲突的更改：
...现在开始变基：
看看冲突是什么：
我已经决定我喜欢来自上游的版本，因此编辑文件来解决这个问题：
暂存该冲突的解决方案：
现在尝试像往常一样继续进行变基：
我认为在最新版本的 git 中，它表明您可能刚刚解决了对已经存在的内容的提交，并且你应该考虑做 git rebase --skip 。然而，通常人们会认为这是摆脱这种情况的唯一方法，因此：
该提交现在不会出现在 git log 中。
3. 合并提交
您在下面的评论中提到，您在检查两个分支时看到了几次合并提交 - 这也可能是丢失提交的原因，因为 git rebase 默认情况下会忽略任何合并提交它准备其提交列表以重新应用到上游。
There are a few possible ways this could happen - this isn't an exhaustive list, but should give you the idea of how this can come about:
1. Cherry-picked commits
Firstly, you mention the possibility that commits from your branch had been cherry-picked into the upstream branch that you're rebasing onto: just to confirm this,
git rebasewill skip any such commits, which might account for some part of the discrepancy. There's more on that in VonC's answer to this question.2. Conflicts resolved to exactly the upstream version
My initial suspicion was that what happened was that when you were rebasing and saw conflicts, you always resolved them by choosing the upstream version rather than your changes. (If this doesn't ring a bell, then my suspicion is probably completely wrong :)) If there were no other non-conflicting changes introduced by that commit, then what your conflict resolution will have done is to just make the tree the same as it was before it tried to apply the patch from your change, so there's nothing to commit.
Unfortunately, the prompts that git gives you when this happens can be rather confusing. Here's an example of what you'll see with git 1.7.1. First, commit a change that's going to conflict with one that's not yet been merged from origin/master:
... now start the rebase:
Look at what the conflict was:
I've decided I like the version from upstream, so edit the file to resolve that:
Stage the resolution of that conflict:
Now try to continue with the rebase as usual:
I think that in more recent versions of git, it suggests that you might have just resolved the commit to what was there already, and that you should consider is doing
git rebase --skip. However, typically people work out that that's the only way out of this situation anyway, so:That commit will now not appear in
git log.3. Merge commits
You mention in the comments below that you saw several merge commits when examining the two branches afterwards - this could also be a cause of missing commits, since
git rebaseby default ignores any merge commits when it prepares its list of commits to reapply onto upstream.要扩展 Jefromi 的评论，您可以将 git log --pretty=oneline -n18 的输出与 git log --pretty=oneline -n25 进行比较;@{1} 并查看哪些提交丢失了。正如他提到的，如果您已经做了一些工作来确定哪个条目是您的预变基分支头，那么您可能需要使用一下 git reflog 。
To expand on Jefromi's comment a bit, you could compare the ouput of
git log --pretty=oneline -n18 <branch>withgit log --pretty=oneline -n25 <branch>@{1}and see which commits went missing. As he mentioned, you might need to usegit refloga bit if you've done some work since to determine which entry is your pre-rebase branch head.