Hg合并后提交消息,最佳做法?

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Hg合并后提交消息,最佳做法?相关的知识,希望对你有一定的参考价值。

我发现自己做了很多事情:

C:Code>hg pull
pulling from http://server/FogBugz/kiln/Repo/Project/Rebuild/trunk
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 4 changes to 4 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)

C:Code>hg merge
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, dont forget to commit)

C:Code>hg commit -m "Merged"

C:Code>hg push
pushing to http://server/FogBugz/kiln/Repo/Project/Rebuild/trunk
searching for changes
remote: kiln: successfully pushed 2 changesets

我的问题是,在合并存储库中的pull之后使用什么是更好/更有用的提交消息。是否存在人们在分布式版本控制系统中使用的最佳实践?

答案

如果你使用fetch extension它会自动拉动,将步骤合并为一步,即获取。它自动生成的消息类似于“自动合并”。 hg开发人员似乎认为这是合理的,因为扩展现在随基础分发。

合并消息似乎不包含特别多的信息。您的信息似乎合理。

[[offtopic,我们有时会将它们用作合并一词的双关语]]

另一答案

没有一种方法,所以这是我试图坚持的。

在提交消息上:

Jus请记住,这些消息是唯一可以将您连接到尝试解释提交原因的人的字符串。

关键是提供一个对代码开发有用的评论。因此,当某人使用hg日志时,他对如何开发软件有一个很好的评论。

一些好的做法:

将其与您的错误管理系统链接:

  1. 修复#3456,新功能#2435等
  2. 或者更具描述性的是它在回购中带来了什么变化
  3. 给予学分

事实上,我所做的主要是。查看“hg log”的当前状态,看看有用的消息意味着理解最新提交的逻辑进展。

另一答案

只要消息中有“merg”,我们就可以利用这个机会充满欢乐。例如,我们使用合并消息,例如“房地产抵押贷款处于历史最低点”或“合并格里芬电视制作”。

另一答案

您可以将所有新添加的变更集的提交消息收集到文件中

$ hg log --rev 'reverse(p2():ancestor(p1(),p2())-ancestor(p1(),p2()))' 
         --template '{desc}
' 
         > commit-message.txt

然后手动编辑commit-message.txt,最后将其用作日志消息:

$ hg commit -l commit-message.txt
另一答案

你可以使用rebase扩展,所以hg pull --rebase会将你的回购重新加入中央回购的提示。这消除了拉动后合并的需要。

我为它添加了一个别名:

[alias]
pure = pull -u --rebase

适合我们。

更多详情请访问RebaseProject页面。

另一答案

对于平凡的合并,你只使用一个存储库,我认为只需“合并”就可以了。通常你甚至不知道所有被合并的东西,因为无论如何它都是其他人的变化。

有一次我建议你更详细的是当你在使用多个存储库时。如果你有一个devel repo和一个稳定的repo,并且你正在从stable中修改bug,我只会在合并中提到:“与stable合并”。这些合并往往更大,所以它有助于向后来的人解释。

以上是关于Hg合并后提交消息,最佳做法?的主要内容,如果未能解决你的问题,请参考以下文章

合并:Hg/Git 与 SVN

在片段中调用 getActivity() 以使其不返回 null 的最佳做法是啥? [复制]

谷歌云消息“未注册”失败并取消订阅最佳做法?

WebStorm:解决冲突后继续与生成的提交消息合并

如何在“hg com”期间获得mercurial来显示差异?

如何只推送到 Hg 中的一个分支?