版本历史真的很神圣吗？还是最好重新设定基础？

我一直都同意Mercurial的口头禅¹，但是，既然Mercurial与rebase扩展捆绑在一起，并且它是git中的流行做法，我想知道它是否真的可以被视为“不良做法”，或者至少足以避免使用。无论如何，我都知道在推送之后重新部署基地很危险。

OTOH，我认为尝试将5个提交打包到一个文件中以使其看起来更整洁（尤其是在生产分支中）的意义，但是，我个人认为能够对部分功能进行部分提交会更好一些实验已经完成，即使它不是很漂亮，但是看到类似“尝试用X来做，但毕竟不如Y，以Y为基数做Z”这样的内容，恕我直言对那些学习的人来说具有很好的价值。代码库，并遵循开发人员的思路。

我非常自以为是（愚蠢，内脏，有偏见）的观点是，程序员喜欢重新设置基础以隐藏错误……而且我认为这根本不适合该项目。

所以我的问题是：您是否真的发现在实践中拥有这样的“有机提交”（即不受干扰的历史记录）很有价值？或者相反，您是否更喜欢遇到包装精美的提交，而无视程序员的实验过程？无论您选择哪个，为什么对您有用？（让其他团队成员保留历史记录，或者根据需要重新建立历史记录）。

根据Google DVCS分析的¹，在Mercurial“历史为神圣”中。

该历史是神圣的，在目前是没有的。您可以将DVCS“树”分为两部分：

• 在过去 /历史它包含的你是如何达到的代码的当前状态的精确视图。历史的这一部分随着时间的流逝而发展

• 在目前这部分你目前的工作，使你的代码发展。这个提示在历史上的大部分都几乎总是相同。

您以某种方式发布或使用的每个代码都是过去的一部分。过去是神圣的，因为您需要能够重现设置或了解是什么引入了回归。您将永远不会改写过去。在git中，您通常永远不会在master中重写任何内容：master是历史的过去。在Mercurial中，您具有此公共阶段概念，该概念可跟踪“树” 的过去部分并强制其不变性。

代码的当前部分是您当前正在使用的变更集。您正在尝试使功能分支可用，无错误并正确重构的分支。重写它是非常好的，这甚至是一个好主意，因为它可使过去的部分变得更加美观，简单和可用。水银在起草阶段对此进行跟踪。

因此，是的，如果可以改善您的历史记录，请重新设置基准。如果您不应该重新装东西，Mercurial可以防止您用脚开枪射击自己。

并非所有的错误都是您需要隐藏的那种错误，例如，我曾经不小心将二进制文件提交给了我的仓库。仅当故障不仅仅存在于历史记录本身中时（例如，不应提交的文件），篡改历史记录才是不好的。

当发生重大的整体变化时，与许多小的相关变化相比，代码审查要容易得多。

当我开发新功能时，我喜欢在分支中进行很多小的更改。当我准备提交补丁时，我会将那些小的提交折叠成一个大的提交，代表该功能所需的所有新代码。这是rebase派上用场的地方。

另一方面，如果提交与彼此无关，则建议不要进行rebase。多个功能的添加应该是单独的提交（最好来自单独的分支）。

您的问题将历史描述为一组有序的代码更改，并询问是否有机地将未来的读者作为线索吸引到开发过程中。但是作为发行/集成工程师，我并不经常将历史视为代码。我更着迷于我的历史讲述的故事，它保留的机构知识以及它是否使我能够快速调试问题。

我认为有机工作流程无法做到这一点，即使我自己也不能做到。我在编码时对DVCS的重视是便宜的分支，快速提交，经常保存到远程，这并不是我作为公司的集成经理所重视的。 我的问题git rebase，git merge，git diff，和git apply更经常在那个角色比git add或git commit。诸如此类的工具rebase可让我将给出的代码从功能正常的部分转换为可以维护的部分。

不合逻辑或含糊的提交没有用，但是当主要关注的是使代码起作用而不将其分发给其他人时，它们很容易有机地编写。像一样提交Case 15: Fixed a problem，或Refactored <cranky legacy feature>使我自己维护自己，即使我编写它们也是如此。但是，没有一个会像“增量”提交那样引起中断的愤怒。考虑一下开发人员前几天交给我的这个主题分支：

$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update

这些都是邪恶的。就像为Faustus博士设计的DVCS。我将为您提供快速简便的源代码控制。您给我是您的代码维护者的灵魂。所有懒惰的行为都是自私的行为。我们中的许多人都编写了它们，但是我们也欠我们自己一个逻辑，可复制，可调试的历史。没有办法我们不可能做得到rebase。

至于失败的实验，为什么不在我们（新原始的）提交消息中描述它们呢？从现在开始的一年，我不需要半成品。我只想记录失败的尝试，如果我认为自己愚蠢到可以再尝试一次，则可能需要简短说明。世界上有许多成功的工作流程，但是我很难考虑我有意将损坏的代码提交到生产代码库的任何原因。

没有什么是神圣的，但请确保您有正当的理由。如果正确使用，重新设置基准将非常强大，但如果使用任何强大的工具，它都会造成混乱并导致问题。

我个人认为在运行最终测试并将功能合并到主分支之前，将本地功能分支根据主干（或主开发分支）重新设置非常有用。这样，我就可以在实际合并之前处理任何合并冲突等。

恕我直言，实验通常属于架子或临时分支，而不是基准。如果您遵循此规则，那应该不会有问题，因为所有提交在逻辑上都是合理的，并会增加一些价值。