首先,你可以推动两个头,但由于你可能不想这样做,默认行为是阻止你这样做.但是,你可以强迫推动.
现在,至于分支,让我们在非分布式版本控制系统(如Subversion)中采用一个简单的场景.
假设您有一位与您在同一项目中工作的同事.Subversion存储库中当前最新的变更集是修订版100,你们都在本地更新,以便现在你们两个都拥有相同的文件.
好的,现在你的同事已经在几个小时内完成了他的改变,所以他承诺了.这使得中央存储库达到了修订版101.您仍然在本地修订版100,并且您仍在处理您的更改.
在某些时候,你完成了,你想提交,但Subversion不会让你.它说你必须先更新,所以你开始更新过程.
更新过程想要进行更改,并假装您实际上是从修订版101而不是100开始.如果您的更改与您的同事提交的任何内容没有冲突,则所有更改都是 hunky dory,但如果您的更改发生冲突,则有一个问题.
现在,您必须将更改与其更改合并,事情可能会变得混乱.例如,你可能最终合并一个文件OK,第二个文件OK,或者你认为,然后第三个文件,你突然发现你有一些错误的细节,它会更好不同地合并第二个文件.
除非您在更新之前备份了更改,否则迟早会忘记,但是您遇到了问题.
现在,上面的场景实际上很常见.好吧,也许不是合并部分,它取决于有多少同时在同一区域或文件中工作,但"提交前必须更新"部分与Subversion相当普遍.
那么Mercurial是如何做到的呢？
好吧,Mercurial在本地提交,它根本不与任何远程存储库通信,所以它不会阻止你提交.
那么,让我们再次尝试上面的场景,这次只是在Mercurial中.
远程存储库中最顶端的变更集是修订版100.您已经克隆了它,并且您已经开始处理修订版100中的更改.
您的同事在当地完成更改并提交.然后,他将他的变更集推送到中央存储库,将其提示升级到修订版101.
然后,您完成更改,并在本地提交,然后您想要推送,但是您收到了您已经发现的错误消息,并且正在询问.
那么这有什么不同呢？
好吧,你的改变现在已经发生了,没有办法,除非你真的很难意外地丢失或摧毁它们.
这是正在播放的3个存储库及其当前状态:
Colleague ---98---99---100---A
Central ---98---99---100---A
You ---98---99---100---B
如果您要推送,并且被允许执行此操作(或强制推送),则中央存储库将如下所示:
Central ---98---99---100---A
\
+--B
两个脑袋.如果你的同事现在被拉了,他应该继续从哪个工作？这个问题是Mercurial默认阻止你造成这个问题的原因.
所以相反,你拉,并在你自己的存储库中获得上述状态.
换句话说,您可以选择影响您自己的存储库并在那里创建多个头,但您不会将此问题强加于其他任何人.
然后你合并,你必须在Subversion中进行相同类型的操作,除了你的变更集是安全的,它已被提交,你不会意外地破坏或破坏它.如果,合并中期,你想重新开始,你可以,没有任何损失,没有伤害.
合并后,您的本地存储库如下所示:
You ---98---99---100---A----M
\ /
+--B--+
这现在可以安全推动,如果你的同事现在拉,他知道他必须继续M变更集,合并他和你的变化.
以上描述是由于Mercurials分布式性质而发生的情况.
您还可以为分支命名,以使其更加永久.例如,您可能希望将分支命名为"stable",以表示该分支上的任何变更集已经过全面测试,并且可以安全地发布给客户或投入生产.然后,只有在完成测试后才能将更改合并到该分支上.
然而,性质与以上描述相同.每当有多个人在Mercurial的项目上工作时,你就会得到分支,这是件好事.
| 归档时间： |
|
| 查看次数： |
175 次 |
| 最近记录： |