在Git rebase之后提交计数在本地分支

时间：2018-05-07 13:38:17

标签： git bitbucket

我在我的测试项目中尝试了Git rebase，以便了解它是如何工作的。可能是我错过了一些微不足道的事情，但我无法弄清楚提交计数如何得到它在日志中显示的值。
我有2个分支机构。大师和开发。任何分支中都没有挂起的提交，这些提交将被推送到远程分支。 这就是它在变形之前的样子： Before Rebase 现在我使用下面的一组命令来执行rebase：

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

确定。我已将更改推送到远程存储库，这就是它现在的样子。 After Rebase

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

  

C：\ GitRepositories \ boney_git_fun＆gt; git status       在分支开发       您的分支机构和＆＃39; origin / dev＆＃39; 有分歧，       并且分别具有 6和2个不同的提交。

本地开发分支如何在rebase之后进行6次提交？我只能想到本地dev分支中的4个提交，它们是：

  1. master commit 4
  2. master commit 5
  3. dev commit 2（在rebased master之上创建的新提交）
  4. dev commit 3（在rebased master之上创建的新提交）

    5. 有谁能告诉我有关失踪的2次提交？如果需要更多信息，请告诉我。

1 个答案:

答案 0 :(得分：2)

诀窍是要意识到一些提交在许多分支上。当您执行rebase时，您更改了标签dev。现在，master 和 master现在只有dev上有 的四个现有提交。 dev上的另外两个提交已不再在dev上;相反， new 提交 - 替换两个旧的; 副本 - 现在位于dev。

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

1 此图形不以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 - 并按照点到点的连接线（文本中的星号和星号复制在这里）。您只能在大致向下的方向上移动，但在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

此图表更易于遵循：提交e09e49b是dev的提示，它及其前身6a8c956仅 < / em> on dev。好之后，之前的，真的......在那之前，我们有6d98d13，这是master的提示并且同时位于master {1}} 和 dev。然后我们有531ae4f，同样在master和dev上，依此类推。

我们现在可以看到，git rebase所做的是复制原始提交c4ef678和1d1165d到新提交分别为e09e49b和6a8c956。 6a8c956的父级是6d98d13，这是master的提示。 c4ef678的父亲当然是1d1165d - 这意味着复制是以相反的顺序发生的，即旧的提交首先被复制，然后是较新的提交：＆＃34;转发＆＃34; Git中的顺序实际上是向后的，因为Git以分支标签所标识的 tip-most 提交开始，然后通过查看每个提交的父级来回溯之前的提交。对于合并提交，通过有两个父母来区分， 2 Git查看两个父母。

由于提交一次可以在多个分支上，因此复制两个dev的行为 - 仅提交两个新提交，这些提交位于 的现有提交的顶部，之前，仅在master上，现在已更改了内容，以便dev上的{em>六个提交之前没有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不在{{1}}。

2 合并提交实际上是对两个或更多父项的任何提交，但是＆＃34;或更多＆＃34;案件有点奇怪。这些提交称为章鱼合并，而章鱼合并实际上从未需要，因此它们主要用于炫耀。 ： - ）

相关问题
最新问题