checkins应该是小步骤还是完整功能？

Question

版本控制的两种用途似乎决定了不同的签到样式。

• 以分布为中心：变更集通常会反映完整的功能。一般来说，这些签到会更大。这种风格更易于用户/维护者。

• 回滚中心：更改集将是单独的小步骤，因此历史记录可以像一个非常强大的撤消功能。通常，这些签到会更小。这种风格更适合开发人员。

我喜欢使用我的版本控制作为非常强大的撤消功能，同时我还在抨击一些顽固的代码/错误。通过这种方式，我不会为了尝试可能的解决方案而做出重大改变。但是，这似乎给了我一个碎片化的文件历史记录，其中有很多“好不通用”签到。

如果我尝试让我的变更集反映完整的功能，我会放弃使用我的版本控制软件进行实验。但是，用户/维护者更容易弄清楚代码是如何发展的。这对于代码审查，管理多个分支等具有很大的优势。

那么开发人员应该做些什么？检查小步骤或完整功能？

Answer 1

  

那么开发人员应该做些什么？检查小步骤或完整功能？

可以充分利用这两个世界，特别是使用git和其他DVCS，让您可以选择要发布哪个历史记录。这是一个简单的工作流程，用于说明这一点。

• 您的项目包含 主 和 发布 分支。开发人员各自维护自己的 开发 分支机构，但不会推送。

• 您使用 开发 来完成日常工作。这里出现了一口大小的提交，代表了项目状态随时间的增长。您可以使用 主题 - * 分支来处理超过几天或主要重构的较长功能。您经常承诺 开发 ，也许每小时几次。这就像在您正在编辑的文档中点击“保存”。

• 如果您有一些适合下一版本的提交，请将相关提交合并到 发布 。 发布 现在有一系列单独的提交，这些提交是从 develop 分支中有选择地提取的。每当您到达一个好的停靠点时，您都​​会承诺 发布 。这通常是一天几次。

• 当发布准备就绪时，您的首席开发人员会将自上次合并后的所有提交压缩到 master ，进入单个合并提交，该提交将出现在<强> 主 即可。然后使用版本标识符（例如，v.1.0.4）标记此提交。这种情况很少发生，可能是一次迭代或每隔几周发生一次。

在这里，你可以吃蛋糕，也可以吃。在发布之前，您可以回滚不应发生的更改或您不想进入发布的更改，并且您可以一次执行一项更改。开发人员友好！但是用户也可以获得他们想要的东西：big，globby提交 master ，代表自上次发布以来发生的变化。

Answer 2

DVCS系统的优点在于您可以两者，因为在DVCS中，与CVCS不同，发布与提交正交。在CVCS中，每个提交都会自动发布，但在DVCS中，提交仅在推送时发布。

所以，提交小步骤，但只有发布工作功能。

如果您担心污染您的历史记录，那么您可以重写它。您可能听说重写历史是邪恶的，但事实并非如此：只重写已发布的历史是邪恶的，但同样，由于发布和提交不同，您可以在发布之前重写未发布的历史记录。

这就是Linux开发的工作原理。 Linus Torvalds非常关注保持历史清洁。在一篇关于Git的早期电子邮件中，他说发布的历史应该看起来不像你实际开发它，而是你如何开发它，如果你是无所不知的，可以看到未来，从未犯过任何错误。

现在，Linux有点特别：它承诺以每11分钟1次提交的速度，每天24小时，每周7天，每年365天，包括夜晚，周末，假期和自然灾害。而且这个比率仍然在增加。想象一下，如果每一个拼写错误和脑力计都会导致提交，那么会有多少提交。

但是开发人员自己在他们的私有存储库中经常提交他们想要的东西。

Answer 3

小步骤。有一个原因，它被称为版本控制，而不是版本控制：）

尽可能经常地提交。别忍住了。在“进行中”分支上提交代码永远不应该有负面影响。期望承诺不“破坏构建”的开发商店滥用RCS。同样，将任何意义归因于提交是危险的策略，仅仅因为它与修订控制的目的相冲突。意思应该归结为标签，分支，克隆，存储或RCS调用它们的任何内容。这些东西具有旨在传达目的的元数据（可能与名称一样小）。修订只是您修改内容的历史记录。

您要做的最后一件事是制定政策，阻止开发人员提交代码，任何原因。

Answer 4

我的建议是为实验目的创建一个分支甚至单独的存储库。然后，一旦该功能完成，您就可以将分支中的代码合并回主代码中。希望这可以让你拥有两全其美的优势。

Answer 5

我真正喜欢Git的一件事是你的开发中的回购。环境是您的回购。这是维护者回购的副本。你可以自由地做任何你想要的回购，除非你推翻一些疯狂的历史，否则你不会勾选维护者。

在这一点上，尽可能多地使用分支和合并来帮助您进行开发和实验。只推动您最熟悉的上游变更。如果需要，Git甚至可以让您将提交历史记录压缩到更少的更改集中，这样您就可以将执行的一系列提交推送到单个提交中。

灵活性极大地增强了您的个人工作流程以及您的同事所拥有的政策。

Answer 6

小步骤非常棒。您可以随时将它们捆绑到另一个仓库中的较大步骤中。要做到相反，你必须“重写历史”，这可以在某些系统中完成（特别是git），但它并不像你想的那样得到很好的支持。

我喜欢小步骤的另一个原因是，我的同事可以很容易地看到我做了什么。如果我工作三四个小时，我通常更加明智地抽出六打提交，以便我的同事可以看到相关的差异。 （我很感激他们给了我同样的礼貌。）

最后，小步骤使您不太可能发生冲突，或者当您这样做时，它们会变小。

即使单独工作，我也会在多个分支上使用小步骤。

摘要：对于日常工作流程，小步骤有许多优点。如果您需要以分发为中心的工作流程，请创建一个仅用于分发的仓库和分支，并且您可以按照您希望的方式设置您的大步骤。

Answer 7

大多数时候我可以遵循以下经验法则 - 在有意义的时间检查最小量（并且仍然有用或改进）。我发现这有助于我更好地规划我的工作，这有几个好处，包括（但不限于）......

• 更好的发展估计。
• 更好的测试估算。
• 更快的开发时间。
• 整体错误减少。
• 模块之间的耦合较少。
• 如果我的代码无意中破坏了其他内容，请尽快找出答案。
• 更多

有时候有必要创建一个分支，然后在完成工作时，将其合并回主线。但是，一旦在分支机构上运营，我仍然会尝试遵循该规则，因为它会自动放弃所有这些好处。

希望这有帮助。