2011-10-25 32 views
0

可能重复:
Introduction to Mercurial水银简单的例子

我最近的变化是微乎其微。我最终做对了吗?

$ hg pull 
warning: code.google.com certificate with fingerprint d2:33:75:af:62:64:5b:75:dc:3f:bf:22:30:b6:27:13:ff:3f:90:fd not verified (check hostfingerprints or web.cacerts config setting) 
pulling from https://[email protected]/p/montao/ 
searching for changes 
adding changesets 
adding manifests 
adding file changes 
added 1 changesets with 1 changes to 1 files 
(run 'hg update' to get a working copy) 
[email protected]:/media/Lexar/montao$ hg update 
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 

所以我不应该做合并,我应该拉?

为什么没有简单的例子说明2个开发人员如何协作?

例如

Time  Developer 1    Developer 2 
       hg clone     hg clone 
       editing 
       hg commit 
       hg push 
             editing 
             hg pull 
             hg commit 
             hg push 

2个开发商像上面之间的工作流程的一个例子将使它更容易理解什么是汞拉,MERG,更新,而不是让我迷惑拉与合并。

例如,我现在知道如何从另一个地方发生变化时不能得到2个头。

我可能需要一个例子说明2个开发人员如何协作以及如何获得远程更改。

回答

1

有关如何使用水银和其他一些VCS我们看看埃里克库的Version Control by Example伟大的深入的示例或Joel Spolsky的hginit.com(我的答案是否会自动降低上市Joel第二?)

1

如果键入hg help pull

它显示:

pull changes from the specified source 

    Pull changes from a remote repository to a local one. 

所以这是RemoteRepository->本地库操作。与您当地的工作目录无关。

如果你键入“汞帮助合并”

merge working directory with another revision 

    The current working directory is updated with all changes made in the requested revision since the last common predecessor revision. 

碰巧你的本地库和本地工作副本之间。与远程回购无关。

如果你要求的例子/手册,网上有很多。我列出一些在这里,希望它对你有帮助。

http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
http://www.rutherfurd.net/2010/apr/22/merging-mercurial-example/
https://www.mercurial-scm.org/wiki/TutorialMerge

5

基本概念

带来了其他开发商的新的变更到自己的仓库。这可能会引入一个新的头,它会这样说,如果它。

合并将两个头合为一体。如果不超过1个头,则不需要合并。

更新在修订之间切换,例如,从当前正在进行的工作版本转换为刚刚插入的版本。如果您有本地未提交的更改,则更新将尝试通过执行未跟踪合并来合并它们。

不管你更新还是合并后都取决于拉是否引入了新头。

简单的两开发商的工作流程

最简单基本的当两个开发者之间的直接合作的工作流程是:

  1. hg pull otherdev
  2. hg updatehg merge
  3. 编辑
  4. hg commit -m "testing..."

pull + update(简写:pull -u)确保您开始使用最新版本的代码。如果你的同事在你最后一次提交和提交之间做出任何改变,这会告诉你它引入了一个新的头,你需要合并。你不必总是拉,你也可以跳过它,只需编辑,提交,编辑,提交(...)一段时间;如果你正在做某件事而不想扰乱你的流量,那么就等待拉动和合并,直到你准备好了(但我至少每天要做一次)。

一般而言,您不应将更改推送给您的同事;通过这种方式,您可以控制存储库中的内容,并且不会因突然出现的新变更集而感到困惑。

注意:通过在步骤3和步骤4之间更新,您可以减少创建分支分支的可能性,在SVN中,这是您不得不做的。不过,我会建议这种做法,因为如果存在冲突,它会使您的更改处于故障状态,并且在修复它之前您将无法提交它。 DVCS的一大优势就是,即您可以避免这种情况,并在不必担心合并之前安全地提交您的工作代码。

改进两开发商的工作流程

为了改善这种工作流程,我真的建议创建第三,共享回购为您和您的同事作为中间使用,而不是从海誓山盟直接拉动。

这引入了一个额外的push步骤,但好处在于,您可以进行一堆提交,并自己决定何时可以通过推送与您的同事共享您的更改。这减少了测试所需的时间,浪费你的同事的时间,因为你不小心弄坏了东西,他把它的可能性。

+0

+1好的和复杂的答案。 – hochl

+0

,当然你可以在你拉之前总是提交,这样你永远不需要做一次未被跟踪的合并 –

+0

谢谢。我得到了拉和合并混合起来。 –