Question

所以我的团队遵循这个流程。

git checkout -b BRA-123

进行更改

git add。
git commit -am＆＃34; BRA-123 - 进行了一些更改＆＃34;
git push origin BRA-123
git checkout master
git merge BRA-123
git push origin master

然后我得到

Total 0 (delta 0), reused 0 (delta 0)

问题是在我推送到BRA-123之后它耗尽了提交，我不能在此时推送到两个分支，而不直接在master中进行更改。

我不确定为什么会这样？有谁知道为什么？

Answer 1

据推测，您的第6步（git merge BRA-123）会导致“快进”合并。也就是说，在第3步，您的提交图看起来像这样：

              C   <-- BRA-123
             /
... <- A <- B     <-- master

这里，新提交C指向其父提交B; B指向A，依旧使用旧提交。

现在，当我说“您的提交图”时，我的意思是您的提交图，位于您计算机上自己的存储库中，而不是您origin上的共享存储库{{ 1}}。

在您的存储库中，标签git push指向提交master，标签B指向提交BRA-123（此处的单个字母）代表像C）那样丑陋的40个字符的SHA-1。

让我们暂时绘制相同的提交图而不用打扰标签：

81e0842b2eb89a882eaa9e11aba7f3d7260bcc75

这次我不需要将... <- A <- B <- C放在单独的行上，因为我不需要分支标签的空间。

当你看到C时，这部分只是提交和他们自己的箭头，是git的计数。这是因为标签位于图表外部，而git正在计算它在图表上的压缩程度。

现在，当您执行第一个Total 0 (delta 0)时，这是完整版git push origin BRA-123的缩写，这意味着“请互联网呼叫（或以其他方式连接到）上列出的机器与远程git push origin BRA-123:BRA-123一起使用的URL，并向他的 git repo提供所需的任何提交和其他图形位，以便他可以将他的 origin设置为指向同一个提交BRA-123指向。“

当然，“他的回购”只有一系列提交以BRA-123结尾。所以你的git与他的git交谈，他们决定你的方必须发送提交... <- A <- B，可能还有一些文件等等。这些加起来不是零，所以你得到一个非零C或其他什么。你的git发送了它，然后他的git检查是否可以设置（或创建）分支Total 3以指向提交BRA-123。假设是，他的git会这样做，你的git会得到一个成功的报告，一切都很好。

现在继续执行第5步（C），然后是第6步（git checkout master）。在第6步中，您告诉您的git找到当前master的tip和git merge BRA-123的提示之间的公共合并基础 - 即，查找commit BRA-123和commit {{之间的最新共享提交。 1}}。那只是提交B本身，这意味着C可以以“快进”方式移动。如果你不禁止这种快速转发，git会这样做：它只是删除旧标签B并将master指向提交master，为您提供：

master

也就是说，两个标签都指向提交C。（这在git-ese中是完全正常的。其他源系统可能总是创建单独的合并提交，即使可以进行快速转发; git 可以执行此操作，但默认情况下不会。）< / p>

现在你继续第7步（... <- A <- B <- C <-- BRA-123, master），让你的git再次调用另一个git。你的git这样做了，它与他的git交谈，他们发现不需要发送提交或其他东西：C。然后你的git要求他的git改变他的git push origin master:master以指向他已经拥有的Total 0。

这要么成功（他的git快速转发master从提交C提交master）或失败，并且像往常一样，你会得到一个单独的失败指示，如果有的话是失败的。可能它成功了。但是，它不会在提交图中添加任何新对象，因为您只是要求其他git快速快进其B分支标签。

Git push branch-a然后与master合并然后推送到master什么都不做？

1 个答案: