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