Hg的标准提交流程是什么？

Question

是吗

1. 拉
2. 更新
3. 融合
4. 提交
5. 推

？或者你可以先做提交吗？

我不喜欢在没有将本地代码版本备份的情况下进行拉动和合并的想法，以防合并爆炸，但可能你必须先进行合并才能进行推送，因为你可以'在中央回购中有冲突。还没完全理解整个过程;习惯了我很好的简单SVN。

Answer 1

我建议在将更改添加到工作目录之前始终提交，除非您100％确定您的更改以及要合并到工作目录中的更改不会发生冲突。

如果您执行更新拉取（hg pull; hg update或更短hg -u pull）并且有任何未完成的未提交更改，则来自外部的任何更改都将与您的更改结合使用。当发生冲突时，可能很难确定合并结果的外观，因为您无法轻易区分您的更改和合并后的更改。

当您首先提交时，更容易确定合并结果的外观，因为您始终可以查看合并的两个父项。 所以，实际上它是：

1. hg commit
2. hg pull -u（如果不需要合并，请转到5）
3. hg merge
4. hg commit
5. hg push

更新：正如Martin Geisler指出的那样，可以使用以下方式获取文件的“原始”更改版本：

hg resolve --unmark the-file
hg resolve --tool internal:local the-file

或同时为所有文件：

hg resolve --unmark --all
hg resolve --tool internal:local -all

但是，我发现“先提交”系统更好。最后，这是个人偏好......

Answer 2

我不知道因为它本身就有一个标准，但Mercurial背后的一个想法是，你可以随心所欲地提交，因为它会转到你的本地存储库。因此，在提取更新之前，您可以尽可能多地投入到内容中。

我倾向于不经常投入，在我准备推动的时候省钱，但那就是我。我可以看到早期和经常提交的效用。当我努力减少合并乐趣时，我会经常提取更新。

我做的另一件事是保持我的工作仓库的并行克隆（从我的工作仓库中克隆到同一个存储库，而不是从我的工作仓库克隆），以便我可以轻松地检查文件的原始状态，以及如果需要，请检查一个带外紧急修复或你有什么事情，而不会使我当前的变更集复杂化。

Answer 3

1. 编辑
2. 提交
3. 转到1直到满意
4. 拉
5. 合并＆amp;提交
6. 如果你想要推。

在尝试执行像合并这样复杂的操作之前肯定会提交。我不认为mercurial会允许你在提交前合并，但即使它确实如此，如果合并出错也会怎样。您没有合并前的修订版本可以返回。

提早提交，经常提交。

如果你不这样做，那你就错过了DVCS的巨大好处。

Answer 4

  

但可能你必须先进行合并才能进行推送，因为你不能在中央回购中发生冲突

错误的声明和对分布式工作流和并行开发的理解不足。

1. 你可以在推送之前合并头，但没有或必须。 Push可以将任何数据放到repo中，如果需要的话也是如此

     

   默认情况下，推送不允许在目的地创建新头，   因为多个头会使人不清楚使用哪个头。在这   情况，建议在推送之前进行拉动和合并。

（注意：“推荐在”声明之前拉动和合并

）

您可以使用commit-pull-merge，stash-pull-unstash-merge，使用修改的WC 执行提取并动态合并，不要合并头或偶尔合并{{ 1 +} + 1头 - 对每个人都没有共同的规则。任何这样的工作流程都不会产生“中央回购中的冲突”，而只会产生不同的DAG 。

在你的（甚至是中央）回购中，来自commmon parent的现有你的和其他变更集的情况下出现的每个分歧点都是启动匿名分支的一个点在Hg，（技术上）绝对合法，适用和通常的方式。他们如何处理由开发人员，PM，QA团队和其他人之间的政策和协议来定义

我个人更喜欢完成我的任务（在一次或多次提交中），拉动后可能合并，当它被开发政策批准时