代码之家 › 专栏 › 技术社区 › Boney

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

bitbucket git

Boney · 技术社区 · 6 年前

我正在测试项目中试用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状态在分支开发上你的 分支和“源/开发” 发生分歧, 并且有 6和2个不同的提交 分别为每个。

本地开发人员分支在重新设置基础后如何有6次提交?我只能想到本地开发分支中的4个提交,它们是:

主提交4
主提交5
dev commit 2(在重新基础的主机上创建的新提交)
dev commit 3(在重新基础的主机上创建的新commit)

有谁能告诉我丢失的2次提交吗?如果需要更多信息,请告诉我。

1 回复 | 直到 6 年前

torek 6 年前

诀窍是要意识到某些提交是打开的 许多的 分支机构。当你做了重新基准时,你改变了标签 dev .四项现有承诺是 ,更早,仅在 master 现在都在 主人 和 开发人员 .其他两次提交 开发人员 不再打开 开发人员 完全相反新承诺更换两个旧的; 副本 -现在开始 开发人员 。

下面是两个提交链(之前和之后,从图像中转录)及其哈希ID。 ^1. 我还添加了分支标签。请注意,提交的哈希ID是其“真实名称”:这是提交的真实标识。这是短日志,例如。, master commit 4 ,只是一个可以复制到新的不同提交的文本字符串。换句话说,那些由十六进制字符组成的杂乱无章的字符串 c4ef678 等等是您应该注意的实际名称。

^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 是只有在…上 开发人员 ;提交 6d98d13 和 531ae4f 和 264c713 和 d3145f2 是只有在…上 主人 ;和 e855864 和以下是打开的 二者都 分支机构。要查看这一点,请从带有分支名称标签的提交开始 c4ef678 对于 开发人员 或 6d98d13 对于 主人 并按照点与点之间的连线(此处文本副本中的星号与星号之间的连线)。您只能在通常向下的方向上移动,但以如下方式合并 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 是提示属于 开发人员 ,及其前身 6a8c956 是只有在…上 开发人员 .Afterwell, 之前真正地在此之前,我们有 6d98d13 ,这是提示属于 主人 两个都有 主人 和 开发人员 .那么我们有 531ae4f ,这在两个 主人 和 开发人员 等等

我们现在可以看到,那是什么 git rebase 确实是为了复制原始提交 c4ef678 和 1d1165d 到新提交 e09e49b 和 6a8c956 分别地的父级 6a8c956 是 6d98d13 ,这是 主人 .的父级 c4ef678 当然是 1d1165d –这意味着复制是按相反的顺序进行的,即先复制旧的提交,然后复制新的提交。Git中的“向前”顺序实际上是向后的,因为Git以 小费最多 提交由分支标签标识,然后通过查看每个提交的父级,返回到以前的提交。对于具有两个父级的合并提交, ^2. Git看着 二者都 父母

由于提交一次可以位于多个分支上,因此复制这两个分支的行为 开发人员 -仅对位于现有提交之上的两个新提交进行提交是 ,之前,仅打开 主人 ,现在已经改变了一些事情六提交时间 开发人员 没有打开 开发人员 之前:复制的两个,以及仅在 主人 。以下是此处报告的六项:

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

如果扫描此处的连接行,可以看到哪些提交是 开发人员 未打开的 原点/偏差 ,哪个是打开的两个 原点/偏差 未打开的 开发人员 。

^2. 合并提交实际上是具有两个 或更多 父母,但“或更多”的情况有点奇怪。这些提交称为 八达通合并 而八达通合并从来都不是 必需的 ,所以它们主要是为了炫耀。:-)