更新:原来是我正在使用的SmartGit版本(版本3.0.11)中的错误-该应用程序类似于gitk。在执行“ git pull”之后,“ Pushable Commits”列表被修改,并且一些尚未推送的本地提交被意外地从该UI列表中删除。这引起了这篇文章中描述的混乱,其中似乎唯一未推送的提交是“合并提交”。
我将更改推送到远程(在GitHub上)。另外两个开发人员在我之后提出了一些承诺。我绝对没有本地更改或提交,并做了“ git pull”。
在撤消更改后,它立即迫使我执行合并提交(允许我键入可选消息)。我已经使用Git大约2年了,但是我还没有遇到过这样的情况:将更改拉入干净的本地仓库会强制执行合并提交。在过去一周中两次发生这种情况,我不确定该怎么做,因此我两次都立即推送了此合并提交而没有任何问题(!?)。
在我们的团队中,我们混合了一些喜欢重新部署基础的开发人员和一些使用git pull的开发人员。我想知道它是否可能相关(即使我们已经进行了一年多的设置,而一周前我都没有遇到过)。我用git pull。
下图显示了历史记录。
我最初提交的内容是紫色线上的底点。另外两个开发人员紧追着我,并在做出更改后在我的本地存储库中创建了最高的“合并分支”提交(在同一紫色线上)。
在看了更长的图像后,我意识到了一些明显的事情。让我们从下到上命名提交A到E,以使其更容易。
事情就是这样:拉之前,您的本地分支指向A
您在本地进行的提交。
但是,当查看提交D时,您会看到红线不是在结尾,A
而是在前面(屏幕截图未显示)。因此,提交不是基于提交的,因此A
在拉动时无法快速前进。您必须创建一个合并提交。
现在您提到您确实曾推送A
过,所以有点奇怪。如果您确实推送了它并且D
已经发布了,那么您的推送将失败,因此您必须先将其合并。如果D
尚未发布,则您的推送将会通过,但是该作者的作者D
必须将其合并才能推送。
由于这两种情况均未发生,并且您在撤回时必须稍后创建合并,因此剩下的唯一原因是您实际上从未推动过提交A
。
请注意,提交并不会自动推送提交。正如我在评论中所说,除非您进行推/拉操作,否则您所做的一切都是完全本地的。而且只有在您进行推入或拉出时,才会实际将提交传输到远程或从远程传输。
(另一种选择是,开发人员推送D
确实发生冲突,但选择强制推送,而从远程存储库中删除提交。如果您使用的是GitHub,则应该在该用户的活动日志中可见。)
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句