如果两个人在跟踪同一个远程分支的分支上工作并且一个人先推送,那么第二个人在他们用另一个人的更改更新他们的分支之前不能推送。
因此,如果我是第二个人,那么在我完成拉取操作后,我的历史会发生什么?我是得到一个合并提交还是做一个 rebase 并将我的更改放在其他人所做的事情的末尾?
如果是前者,那么这是否意味着即使我的分支正在跟踪远程分支,它实际上有不同的历史记录?
如果两个人在跟踪同一个远程分支的分支上工作并且一个人先推送,那么第二个人在他们用另一个人的更改更新他们的分支之前不能推送。
因此,如果我是第二个人,那么在我完成拉取操作后,我的历史会发生什么?我是得到一个合并提交还是做一个 rebase 并将我的更改放在其他人所做的事情的末尾?
如果是前者,那么这是否意味着即使我的分支正在跟踪远程分支,它实际上有不同的历史记录?
这取决于您如何拉动更改
这样做git pull
会导致本地分支和远程分支的合并提交。
Doinggit pull --rebase
会将您的更改移至遥控器上发生的任何更改之后。
根据手册http://git-scm.com/docs/git-pull
pull
是git fetch
和git merge
命令的组合。将--rebase
第二个命令的更改添加到git rebase
在这两种情况下,您的历史记录都与远程的不同,因为您在本地进行了提交(可能还有合并提交)。这就是为什么您会在状态中看到您“领先 X 次提交”的原因。直到您推送,在这种情况下,远程和您的本地历史将是相同的......直到其他人推送。
在这种git pull
情况下,如果你用git log --graph
. 您将在提交之前看到历史记录拆分(这是您当时从远程进行的最后一次提交)。然后会有一个分支显示第二个人的提交,另一个显示你的提交。这些分支将在第三次提交时加入,例如“将分支 master 合并为 master”。这是解决分支和远程之间差异的合并提交。
这样做git pull --rebase
,日志将是第二个人提交的一行,然后是您的提交。
当你们都处理同一个提交时,你正在分叉分支。分支可以通过合并提交将其他分支拉到一起,但它们不能分开并且仍然是一个分支。要遵循两条独立的开发路线,您需要为每个分支负责人命名。当您和另一个人在您自己的存储库上创建单行提交时,您可以自由地继续使用相同的分支头名称,因为您甚至不知道其他地方还有其他工作。
但是,当您想将它们拉回到一起时git pull
,您需要解决这个问题。您可以git pull --rebase
找到您分歧的点,并在从其他人获取的提交之上重放您的提交(更改您的历史记录),或者 - 默认情况下 - 将来自服务器的传入提交合并到您的分支将两个分支的最新提交放在一起。
这有效地在您的两个分支之上添加了一个新提交(因此不会更改服务器上的历史记录,而只是添加一个),并且从服务器副本的角度来看,树的快照只是服务器的工作加上您合并的工作,因此合并提交的树看起来就像您的分支上的所有工作都一次性编辑到其中。合并提交包含指向两个父哈希的链接这一事实意味着任何人仍然可以看到您的更改突然来自何处,并查看您分支上的提交以更精细的方式跟踪您的工作。
您可以将服务器的分支版本视为您分支的另一个分支。如果你们中的任何一个继续前进,那么你们已经分道扬镳了。在本地解决该问题(即,将功能带回主控)的方法是将分支重新合并在一起,或者将其中一个重新置于另一个之上。解决跨 repos 分离的同一分支的两个版本的方法完全相同 - 将一个合并到另一个,或将一个重新定位到另一个。
我现在明白为什么我感到困惑了。我假设 Git 像 SVN 一样维护一个提交线程。相反,它会跟踪已分歧的克隆分支。