Hg 合并后提交消息，最佳实践？

Question

我发现自己经常做以下事情：

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

我的问题是，在合并来自存储库的拉取后，可以使用什么更好/更有用的提交消息。人们在分布式版本控制系统中是否有针对此类事情使用的最佳实践？

Answer 1

如果您使用提取扩展，它会自动执行拉取、合并步骤到一步、提取。它自动生成的消息类似于“自动合并”。 hg 开发人员似乎认为这是合理的，因为扩展现在与基础一起分发。

合并消息似乎不包含特别大量的信息。你的消息看起来很有道理。

[[题外话，我们有时用它们作为“合并”一词双关语的机会]]

Answer 2

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

关于提交消息：

请记住，这些消息是唯一可以将您与尝试破译提交原因的人联系起来的字符串。

关键是提供对代码开发有用的描述。
因此，当有人使用 hg log 时，他会对软件的开发方式有一个很好的评论。

一些好的做法：

将其与错误管理系统链接：

1. 修复#3456、新功能#2435等
2. ，或者更具描述性的它在存储库中带来的更改之一
3. 给予积分

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

Answer 3

只要消息中以某种方式出现“合并”，我们就会利用这个机会让我们的善变日志充满欢乐。例如，我们使用了诸如“房地产合并贷款处于历史最低水平”或“合并格里芬电视制作”之类的合并消息。

Answer 4

您可以通过手动编辑 commit-message.txt 将所有新添加的变更集的提交消息收集到一个文件中

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

，最后将其用作日志消息：

$ hg commit -l commit-message.txt

Answer 5

您可以使用 rebase 扩展，因此 hg pull --rebase 会将您的存储库重新设置为中央存储库的提示。这消除了拉取后合并的需要。

我为它添加了一个别名：

[alias]
pure = pull -u --rebase

对我们来说效果很好。

更多详细信息请参见 RebaseProject 页面。

Answer 6

对于只使用一个存储库的普通合并，我认为“合并”就可以了。通常您甚至不知道合并的所有内容，因为无论如何都是其他人的更改。

有一次我建议更加详细的是当您使用多个存储库时。如果您有一个开发仓库和一个稳定仓库，并且您正在从稳定仓库中提取错误修复，我只会在合并中提到：“与稳定合并”。这些合并往往规模更大，因此有助于向后来的人解释它们。