Git重新设置后在本地分支中提交计数

Question

我正在尝试在测试项目中对Git重新进行基准测试，以了解其工作原理。 可能是我遗漏了一些琐碎的事情，但是我无法弄清楚提交计数如何获得它在日志中显示的值。

我有两个分支。 大师和开发 任何分支中都没有待处理的提交，这些提交将被推送到远程分支。 这是变基之前的样子： 现在，我使用以下命令设置基准：

C:\GitRepositories\boney_git_fun>git checkout dev

C:\GitRepositories\boney_git_fun>git rebase master
First, rewinding head to replay your work on top of it...
Applying: dev commit 2
Applying: dev commit 3    

C:\GitRepositories\boney_git_fun>git status
On branch dev
Your branch and 'origin/dev' have diverged,
and have 6 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
nothing to commit, working directory clean

C:\GitRepositories\boney_git_fun>git push --force

好。 我已将更改推送到远程存储库，这就是现在的样子。

现在我的问题。 在下面的日志中，

C：\\ GitRepositories \\ boney_git_fun> git status在分支dev上您的分支和'origin / dev'已经分开，分别具有6和2个不同的提交 。

重新建立基础后，本地dev分支如何进行6次提交？ 我只能想到本地dev分支中的4个提交，它们是：

1. 主提交4
2. 主提交5
3. 开发者提交2（在基于主服务器的基础上创建的新提交）
4. 开发者提交3（在重新建立基础的master之上创建的新提交）

有人可以告诉我有关缺失的2个提交吗？ 让我知道是否需要更多信息。

Answer 1

诀窍是要意识到一些提交在许多分支上。 重新设定基准时，您更改了标签dev 。 那是 ，早些时候，只在现有四个提交master现在两个master 和 dev 。 在dev人员身上的另外两个提交根本不再在dev人员身上。 而是新提交-替换两个旧提交； 副本 -现在在dev 。

这是两个提交链（从图像转录的前后）及其哈希ID。 ¹我还添加了分支标签。 请注意，提交的哈希ID是其“真实名称”：这是提交的真实身份。 它是一个简短的日志，例如master commit 4 ，只是一个文本字符串，可以将其复制到新的不同提交中。 换句话说，那些用十六进制字符c4ef678等组成的c4ef678字符串是您应注意的实际名称。

---

¹该图的绘制方式不是 git log --graph --oneline绘制方式，它是图像的文字转录。 --graph选项在git log打开拓扑排序，这将更改提交在每行输出中的聚集方式，并且还尝试以特定方式绘制合并的第一和第二父级，而这两者都不是案例在这里。

---

之前：

*    c4ef678  dev commit 3      (dev)
| *  6d98d13  master commit 5   (master)
| *  531ae4f  master commit 4
* |  1d1165d  dev commit 2
| *  264c713  Merged dev into master
|/|
| *  d3145f2  master commit 3
* |  e855864  dev commit 1
|/
*    e90a213  master commit 2
*    abe2416  master branch commit
*    6685b20  README.md created online with Bitbucket

注意，提交c4ef678和1d1165d 仅在dev ； 提交6d98d13和531ae4f以及264c713和d3145f2 仅在master ; 和e855864及以下版本在这两个分支上。 要看到这一点，请从带有分支名称c4ef678的提交开始-对于dev来说是6d98d13对于master 6d98d13并遵循从6d98d13的连接线（此处为文本副本中的星号到星号）。 您只能沿一般向下的方向移动，但是在像264c713这样的合并264c713 ，沿两条线向下移动。

后：

*    e09e49b  dev commit 3     (dev)
*    6a8c956  dev commit 2
*    6d98d13  master commit 5  (master)
*    531ae4f  master commit 4
*    264c713  Merged dev into master
|\
* |  d3145f2  master commit 3
| *  e855864  dev commit 1
|/
*    e90a213  master commit 2
*    abe2416  master branch commit
*    6685b20  README.md created online with Bitbucket

该图更容易遵循：commit e09e49b是dev的技巧 ，它及其前身6a8c956 仅在dev 。 之后–好吧， 之前 ，真的...在那之前，我们有6d98d13 ，这是master的技巧 ，同时在master 和 dev 。 然后，我们有了531ae4f ，同样在master和dev也是如此，依此类推。

现在，我们可以看到git rebase所做的是分别将原始提交c4ef678和1d1165d 复制到新的提交e09e49b和6a8c956 。 的父6a8c956是6d98d13 ，它是尖master 。 的父c4ef678当然1d1165d哪位是指以相反的顺序复制发生，即老提交首次得到了复制，然后将更新的一个：在Git的“前进”命令实际上是倒退，正如吉特与提示-开始由分支标签标识的大多数提交，然后通过查看每个提交的父级返回上一个提交。 对于以两个父母为特征的合并提交， ² Git会同时检查两个父母。

由于提交可以在同一时间内超过一个分支，复制这两个行为dev -只承诺对这些坐在那名之前，只对现有的提交顶上两个新提交master ，现在已经改变了一些事情，以便有在dev上有六次提交，而以前没有在dev ：复制的两次，以及仅在master上的四次。 这些是这里报告的六个：

 Your branch and 'origin/dev' have diverged, and have 6 and 2 different commits each, respectively 

这两个仅在origin/dev -这也是您自己的存储库中的标签； 它是您存储库中存储的内容或origin -是复制之前的原始两个。 也就是说，如果我们将它们画进去，我们将得到一个稍微复杂一些的图形：

*      c4ef678  dev commit 3     (origin/dev)
*      1d1165d  dev commit 2
| *    e09e49b  dev commit 3     (dev)
| *    6a8c956  dev commit 2
| *    6d98d13  master commit 5  (master)
| *    531ae4f  master commit 4
| *    264c713  Merged dev into master
| |\
| | *  d3145f2  master commit 3
|/  |
*   |  e855864  dev commit 1
|  /
| /
|/
*      e90a213  master commit 2
*      abe2416  master branch commit
*      6685b20  README.md created online with Bitbucket

如果您在此处扫描连接线，则可以看到哪些提交是dev上的六个提交，它们不在origin/dev ，哪些是在origin/dev上的两个提交，不在dev 。

---

²合并提交实际上是具有两个或更多父母的任何提交，但是“或更多”的情况有点奇怪。 这些提交被称为章鱼合并，而章鱼合并实际上并不需要 ，因此它们主要是为了炫耀。 :-)