3

将干净代码推送到主分支的最佳实践是什么？

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

拥有大量贡献者的大型项目如何保持主要开发分支的清洁？

我从中央存储库中提取源代码的副本，然后使用分支、标签、实验代码的本地合并和提交进行大量本地更改，直到所有内容都经过测试并正常工作。

现在我进行最终提交并将我的更改推送回主干 - 这会将我本地更改的完整历史记录发送到中央服务器。

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

有没有一种最佳实践方法来减少我的推送，使其只包含干净的代码？清理我的代码（使用折叠或其他扩展）是我的责任，还是主管选择清理位并将它们复制到“最终版本”存储库？

非常感谢您的帮助，

史蒂夫

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

回答：我已经接受了 Tims 下面的回答以及他给出的关于 github 的链接，特别是 [ github.com/git/git/blob/master/Documentation/SubmittingPatches ]。所以是的 - 在将您的提交推送到中央存储库之前清理它！

4

1 回答 1

5

首先，您需要与您的主管讨论您项目的预期工作流程。以下一般建议对于大多数情况应该是好的，但您的项目可能有理由以不同的方式做事。

一般来说，您应该努力使您的存储库的发布历史尽可能干净。清洁度可以通过以下方式判断：

  • 小而有凝聚力的变更集
  • 清理或重构应与新功能分开提交。
  • 每个提交都应通过测试（以允许使用诸如 等工具bisect）

在所有 DVCS 中，都有本地与已发布历史的概念。在大多数工作流中，一旦变更集被推送到其他人克隆的公共存储库，它就被认为已发布。

关于编辑回购历史有两个基本规则：

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

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

在大多数项目中，开发人员需要在提交代码以供审查或发布之前清理自己的代码。这样可以避免审阅者/集成者将时间浪费在凌乱的工作上。

于 2012-06-26T12:48:10.640 回答