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

aut*_*gic 15 mercurial

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

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
Run Code Online (Sandbox Code Playgroud)

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

Pau*_*bel 9

如果你使用fetch扩展,它会将pull,merge步骤自动化为一步,fetch.它自动生成的消息类似于"自动合并".hg开发人员似乎认为这是合理的,因为扩展现在随基础分发.

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

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

  • 只是为了在我的downvote背后插入一个原因:我认为pyfunc的建议是他们给出"为什么"真的是一个更好的主意.我的倾向于"从生产分支引入错误修正#"或"拉入吉姆的新功能Y".fetch扩展随mercurial一起提供,但默认情况下它被禁用,并且有充分的理由. (2认同)
  • @ Ry4an我可以看到你在说什么,但大多数合并只是其他人的发展.这些提交中的内容已经在日志中,包含给定的补丁.如果你合并的东西与其他两个人合并,那么合并可能是一个很大的漏洞.如果你可以简明地说出合并的内容,那么这样做似乎是合理的,但至少在我的开发中我并不经常看到这种情况. (2认同)

pyf*_*unc 6

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

在提交消息上:

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

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

一些好的做法:

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

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

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