将清洁代码推送到Mercurial主分支的最佳实践是什么?

时间:2012-06-26 10:34:22

标签: git mercurial dvcs

将干净代码推送到主分支的最佳做法是什么?

这是关于Mercurial的最佳实践问题,但其他DVCS / git用户的想法也适用。如果有合适的网站,请指出。

有很多贡献者的大型项目如何保持主要开发部门的清洁?

从中央存储库中提取源代码的副本,然后使用分支,标记,实验代码和提交的本地合并进行一系列本地更改,直到所有内容都经过测试和运行。

现在我将最终提交推送我的更改重新添加到主干 - 这将发送 完整历史记录 < / strong>我对中央服务器的本地更改。

这在概念上很好,但这意味着执行最终构建的主管可以看到我所有的实验和错误代码都在为最终测试版本工作。

是否有最佳实践方法来减少我的推送,以便它只包含干净的代码?是我可以清理我的代码(使用折叠或其他扩展),还是主管选择干净的位并将它们复制到“最终版本”存储库?

非常感谢您的帮助,

史蒂夫

=======================

回答:我已经接受了Tims的回答以及他给出的关于github的链接[github.com/git/git/blob/master/Documentation/SubmittingPatches]。所以是的 - 在将其提交到中央存储库之前清理您的提交!

1 个答案:

答案 0 :(得分:5)

首先,您需要与您的主管讨论项目的预期工作流程。以下一般建议应该适用于大多数情况,但您的项目可能有理由采取不同的做法。

通常,您应该努力使存储库的已发布历史记录尽可能干净。清洁度可以通过以下方式判断:

  • 小而有凝聚力的变化集
  • 清理或重构应与新功能分开进行。
  • 每次提交都应通过测试(以允许bisect
  • 等工具

在所有DVCS中,都有本地已发布历史记录的概念。在大多数工作流程中,一旦将变更集推送到其他人已克隆的公共存储库,就会将变更集视为已发布

有关编辑回购历史的两条基本规则:

  1. 发布变更集后,您不应修改历史记录。这意味着仅推送准备发布的变更集非常重要。在Mercurial术语中,不要hg push所有传出的更改。相反,请使用hg push -b <branch>hg push -r <rev>执行特定更改的目标推送。有关更具体的推理和建议,请参阅Mercurial wiki上的EditingHistory

  2. 在发布更改集之前(例如,当它们是本地的)时,您可以根据需要自由修改,变基,折叠等,以创建“干净”的历史记录。在git中,这个使用git commit --amendgit rebase完成。 Mercurial具有queues (mq)histeditcollapse等扩展程序。

  3. 在大多数项目中,开发人员应在提交审核和/或发布之前清理自己的代码。这样可以避免审稿人/集成商在杂乱的工作上浪费时间。