在Git重新基址后提交本地分支中的计数_Git_Bitbucket

在Git重新基址后提交本地分支中的计数

git

在Git重新基址后提交本地分支中的计数,git,bitbucket,Git,Bitbucket,我正在我的测试项目中尝试Git rebase，以便了解它是如何工作的。可能我遗漏了一些琐碎的东西，但我无法弄清楚提交计数是如何获得它在日志中显示的值的。我有两个分支机构。Master和Dev。在任何要推送到远程分支的分支中都没有挂起的提交。这就是重新设定基准之前的情况：现在，我使用以下一组命令重新设置基础： C:\GitRepositories\boney_git_fun>git checkout dev C:\GitRepositories\boney_git_fun>gi

我正在我的测试项目中尝试Git rebase，以便了解它是如何工作的。可能我遗漏了一些琐碎的东西，但我无法弄清楚提交计数是如何获得它在日志中显示的值的。

我有两个分支机构。Master和Dev。在任何要推送到远程分支的分支中都没有挂起的提交。这就是重新设定基准之前的情况：现在，我使用以下一组命令重新设置基础：

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\u git\u fun>git状态关于分支开发您的分支和'origin/dev'已发生分歧，分别有6次和2次不同的提交

本地开发分支在重设基础后如何有6次提交？我只能想到本地开发分支中的4个提交，它们是：

主提交4

主提交5

dev commit 2（在重定基址的主机上创建的新提交）

dev commit 3（在重定基址的主机上创建的新commit）

有谁能告诉我丢失的两件事吗？如果需要更多信息，请告诉我。

诀窍是要意识到一些提交在许多分支上。当您重新设置基础时，您更改了标签

dev

。先前仅在

master

上的四个现有提交现在同时在

master

和

dev

上。在

dev

上的另外两个提交不再在

dev

上；取而代之的是，新提交的文件替换了两个旧文件；副本现在位于

dev

上

下面是两个提交链（之前和之后，从图像中转录）及其哈希ID。1我还添加了分支标签。请注意，提交的哈希ID是其“真实名称”：这是提交的真实标识。它是短日志，例如，

主提交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

*    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

请注意，提交

c4ef678

和

1d1165d

仅在

dev

上；提交

6d98d13

和

531ae4f

和

264c713

和

d3145f2

仅在

master

上；和

e855864

及以下是在两个分支上。要看到这一点，请从带有分支名称标签的提交处开始，对于

dev

，从带有分支名称标签的提交处开始，对于

master

，从带有分支名称标签的提交处开始，然后按照连接线从点到点（此处文本副本中的星号到星号）。您只能沿通常向下的方向移动，但在类似于

264c713

的合并处，请沿两行向下移动

之后：

*    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

*    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中的“forward”顺序实际上是向后的，因为Git从分支标签标识的最顶端提交开始，然后通过查看每个提交的父级，返回到以前的提交。对于合并提交，其区别在于有两个父级，2git同时关注两个父级

由于提交一次可以在多个分支上进行，因此复制两个

dev

-只提交到两个新的提交，这两个新的提交位于之前仅在

master

上的现有提交之上，现在已经改变了情况，因此在

dev

上有六个提交之前没有在

dev

上：复制的两个，而只有在

master

上的四个。以下是此处报告的六项：

只有在

源代码/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

上）

2A合并提交实际上是任何具有两个或更多父级的提交，但“或更多”的情况有点奇怪。这些提交被称为八达通合并，实际上并不需要八达通合并，因此它们主要用于炫耀。：-）

您的分支图很难阅读，如果包含