作为Subversion的前用户,我们决定转向Mercurial进行SCM,这让我们感到困惑.虽然Mercurial是一个分布式SCM工具,但我们使用远程仓库来保持我们在服务器上备份的更改,但我们发现了一些问题.
例如,当我们两个或三个人在我们的本地仓库上工作时,我们提交然后推送到远程仓库,我们发现创建了很多头(？).这混淆了我们的地狱,我们不得不做一些合并等来解决它.
什么是避免这么多头脑并使远程仓库与许多开发人员保持同步的最佳方法？
今天,我一直在这样工作:
这是最好的进程吗？
虽然这在今天运作良好,但我不禁感到我做错了!说实话,我不明白为什么合并甚至需要在拉动阶段完成,因为其他人正在处理不同的文件？
除了告诉我RTFM你有任何使用Mercurial的提示是这样的吗？有什么好的在线资源可以获得有关我们为何如此多头的信息？
注意:我已经阅读了手册,但它并没有提供太多细节,我不认为我想在一分钟开始另一本书.
ang*_*son 11
你一定要找到一些学习资源.
我可以推荐以下内容:
至于你的具体问题,"这是最好的程序",那么我就不得不说.
这是一些提示.
首先,您无需始终与中央存储库保持"同步".相反,请遵循以下准则:
换句话说,这是典型的一天.
当你早上进来时,你会提取最新的更改,以便获得最新的本地克隆.你可能并不总是这样做,如果你正处于你昨天没有完成的更大变化的中间.
然后你开始工作了.您提交了具有独立更改的小变更集这并不是说您将更大的错误修正分成许多较小的提交只是因为您修改了多个文件,但是尝试避免一次修复多个错误,或者实现多个功能一次.尽量保持专注.
然后,当您对本地添加的所有更改集感到满意时,您决定推送到服务器.当您尝试执行此操作时,会收到一条中止消息,指出额外的磁头将被推送到服务器,这是不允许的,因此推送将被中止.
相反,你拉.这总是可以完成的,但是当然现在会在本地克隆中添加额外的头,而不是在服务器上.
然后,您将从服务器获得的额外头部与您自己的头部合并,即您在白天通过向克隆提交新的更改集而创建的头部.您解决任何合并冲突.
然后你推,现在它应该成功.如果有人在您忙着合并时设法将更多变更集推送到中央存储库,那么您将获得另一次中止并且必须冲洗并重复.
历史记录现在将显示多个并行的开发分支,但应始终保持在中央存储库中最多1个头.如果,稍后,您开始使用命名分支,则每个命名分支可以有1个头,但是在您获得默认分支的挂起之前,请尽量避免这种情况.
至于为何需要合并？好吧,Mercurial总是使用作为整个项目快照的修订,这意味着两个分支,即使它们包含对不同文件的更改,实际上被认为是整个项目的两个不同版本,你需要告诉Mercurial它应该结合起来他们回到一个版本.
| 归档时间： |
|
| 查看次数： |
595 次 |
| 最近记录： |