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

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

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

拥有众多出资人的大型项目如何保持主要开发部门的清洁

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

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

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

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

非常感谢你的帮助

史蒂夫

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

---

答案：我已经接受了Tims下面的答案，特别是他给出的关于github的链接[]。所以是的-在将提交内容推送到中央存储库之前，请先清理提交内容

首先，你需要和你的主管谈谈你项目的预期工作流程。下面的一般建议对于大多数情况都是好的，但是您的项目可能有理由做不同的事情

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

• 小的、内聚的变更集
• 清理或重构应该与新特性分开提交
• 每次提交都应通过测试（以允许使用以下工具）

在所有DVC中，都有本地历史与出版历史的概念。在大多数工作流中，变更集被推送到其他人克隆的公共存储库后，即被视为已发布

关于回购历史记录的编辑，有两条基本规则：

发布变更集后，不应修改历史记录。这意味着只推送准备发布的变更集很重要。用反复无常的话来说，不要推送所有即将进行的更改。相反，使用

hg push-b

或

hg push-r

执行特定更改的目标推送。有关更具体的推理和建议，请参见Mercurial wiki

在发布变更集之前（即当变更集是本地的时候），您可以根据需要修改、重设基础、折叠等，以创建“干净”的历史记录。在git中，这是使用或完成的。Mercurial具有扩展，如和

---

在大多数项目中，开发人员都希望在提交代码供审查和/或发布之前清理自己的代码。这样可以避免评审员/集成员在繁杂的工作上浪费时间。

拥有完整的变更历史记录不是VCS的重点吗？我假设在发布时，主管只会从主干中获取最新版本并构建它。类似于此：@AlexFlorescu和VBwhatnow-是的，它是类似的（这就是我发现“崩溃”的原因）但是我无法想象linux内核项目在它的主目录树中有每一个微小的实验性变化——当然Linus必须以某种方式充当一个编辑器吗？@VBwhatnow OP的请求很有意义。例如，当您进行二等分时，尽可能减少中断某些内容（无论是构建还是测试）的提交次数是一件非常、非常、非常好的事情。好的，这很有意义，让贡献者负责确保他们的代码干净且可读。因此，一个工作流可能是您拉主分支，使用多个本地分支和提交尽可能多地进行操作。然后，为了获得一个干净的版本，可以将主分支重新拉到一个新的目录，复制最后的工作代码，重新测试并将其推回到主分支上——这就是大型开源项目所做的吗？创建重复的克隆可能是过火了。大多数情况下，您可以在repo中的一个功能分支上进行实验，根据需要修改历史以使其干净，并在完成后推送结果。开源项目往往表现不同。很少有人能够推式访问开源回购协议。对于像

git

和

mercurial

这样的项目，贡献者通过电子邮件提交补丁供审查（而不是推送）。如果维护者同意，那么他将把补丁集成到受限访问公共回购中。更多信息请参见。蒂姆-谢谢你的链接，这是我一直在寻找的。这听起来就像以前用一张5英寸的软盘把代码交给图书管理员一样！