更新:这是我正在使用的SmartGit版本(版本3.0.11)中的一个错误 - 一个类似于gitk的应用程序。在执行“git pull”之后修改“Pushable Commits”列表,并且从该UI列表中意外删除了一些尚未推送的本地提交。这引起了这篇文章中描述的混淆,其中似乎唯一没有推送的提交是“合并提交”。
我将更改推送到远程(在GitHub上)。另外两个开发人员在我之后推了几个提交。我绝对没有本地更改或提交,并做了“git pull”。
在拉下更改之后,它立即强制我进行合并提交(允许我输入可选消息)。我已经使用Git约2年了,我还没有遇到这种情况,即将更改下拉到干净的本地仓库会强制进行合并提交。过去一周发生了两次这种情况,我不知道该怎么做,所以我立刻推动了这次合并提交,没有任何问题(!?)。
在我们的团队中,我们有一些喜欢变调的开发者和其他使用git pull的开发者。我想知道它是否可能相关(即使我们已经有一年多的设置并且我在一周之前没有遇到过这种情况)。我用git pull。
下图显示了历史记录。
我推送的原始提交是紫色线上的底部点。另外两个开发人员在我之后推动了他们的改变,它在我的本地仓库(在同一条紫色线上)创建了顶级的“合并分支”提交。
答案 0 :(得分:1)
在看了你的图像更长时间后,我意识到了一些明显的东西。让我们从下到上命名提交A到E,以便更容易。
所以这就是事情:在拉动之前,你的本地分支指向A
,这是你在本地提交的。
然而,当查看提交D时,您可以看到红线不会在A
中结束,而是在某处之前(屏幕截图未显示)。因此,提交不是基于A
,因此在拉动时你无法快进。您必须改为创建合并提交。
现在你提到你之前推过A
,所以这有点奇怪。如果你真的推了它并且D
已经发布了,你的推送就会失败,你必须先合并它。如果D
尚未发布,那么您的推送就会完成,但是D
的作者必须先合并它才能推送它。
由于你没有发生任何事情而且你必须在以后拉动时创建合并,唯一的原因是你实际上从未推动过你的提交A
。
请注意,提交不会自动推送提交。正如我在评论中所说,除非你推/拉,否则你所做的一切都完全是本地的。只有当您执行推送或拉取时,提交才会实际传输到远程或从远程传输。
(另一个选择是dev推动D
发生冲突但是选择强制推送,从远程存储库中删除你的提交。如果你使用的是GitHub ,这应该从该用户的活动日志中可见。)
答案 1 :(得分:0)
要记住的重要一点是git pull
是两个命令的组合。 git fetch
和git commit
此外,您的本地主分支与远程主分支不是同一分支。
推送更改后,有人将更改推送到远程分支。所以当你从遥控器拉出来的时候。 Git更新了远程分支的HEAD
,然后将其合并到您的本地分支中。合并导致提交发生,因此您最终将进行合并提交。
如果您已将分支重置为最初推送的提交,然后执行git pull --reabse
,您会发现其他开发人员添加的提交将与您的分支一致,并且您不会合并提交。
通常这些合并提交是良性的,但偶尔也会造成一些麻烦。
从您的评论中,当您推送本地有一个或多个提交而不是您的遥控器。在你推动之后,它们就等同了。