频繁或罕见的来源签到？

Question

我只是检查了我的代码并意识到我不知道我的代码应该在理想情况下满足哪些条件来执行签入。

昨天我检查了我的项目一周后检查了。今天我做了一些更新后再次登记入住。有时我喜欢保留我正在检查的代码，直到它可以通过一些测试。

我的老板通常抱怨人们在周末或假期检查代码，所以我尽量避免这种情况（如果没有其他原因，因为我忘了我正在做的事情）。

我是否应该担心会遇到大量代码或者无法找到错误，因为搜索的代码太多了？

Answer 1

应经常检查ins。

登记入住

• 原子。包含所有必需的更改，但不再包含。这也意味着
• 空白更改继续进行。
• 只更改一项功能。这可能会改变几个功能，但它不应该以多种方式和/或地方改变功能。
• 评论。签入注释应该可以让您快速找到提交，即使它已经有2年了，而且您不再处理该特定来源（甚至是项目）。
• 工作。只有在代码实际构建并执行它声称要执行的操作时才提交。

如果你需要你的私人游乐场来考虑一个工作分支或用git svn之类的东西镜像存储库。请记住尽可能以原子方式合并更改。这可能是更多的工作，但如果您需要确定更改或可能破坏某些内容的提交，它会立即得到回报。

Answer 2

我可以推荐以下指南：

• 每次签入都应该是“原子的”，这意味着您只需要更改系统的一部分。不建议使用一个大的检查来改变很多东西，因为这样就很难恢复一个变化。
• 在经过彻底测试之前，请不要检查代码。
• 请在准备好后立即签入代码。它适用于备份目的，因为您的工作副本与源代码管理中的最新更改不同步，所以它在那里的时间越长。
• 无论是频繁登记还是不频繁登记，磁盘空间应大致相同。
• 如需搜索，请确保您的办理登机手续附有评论。

Answer 3

提前和经常入住，就像投票一样。

有一点需要注意的是，整合过程的工作方式会有所不同。如果您有持续集成，除非您运行单元测试并确信它能够正常工作，否则您不希望将内容重新检入 trunk 。

协调这两件事的方法是为您的工作区创建一个分支，经常在分支上签入，并在您创建和测试更改时合并。在许多变化中进行大合并的烦恼将鼓励你将它们分解成小步骤。这是件好事。

Answer 4

如果您的源代码管理系统允许，我更喜欢创建一个私有分支或活动，并且至少每天都要对其进行检查，或者如果我要开始有风险的事情，则更频繁地进行检查。我只是合并或交付，以便在我正在工作的位之后可以访问其他人。

Answer 5

尽可能实际，我尽量让我的签到尽可能精细，条件是我不会/不检查a）不编译的任何东西，b）打破单元测试，或c）打破向后兼容性（除非它以这种方式请求/设计）。

如果我担心在我的机器上留下新的或更新的代码一段时间我通常创建（或要求创建）一个临时分支供我自己使用，但我只使用它的时间很短在此之前，我必须重新加入我正在工作的分支机构。

Answer 6

如果需要考虑磁盘空间，那么您确实需要更大的硬盘驱动器。即使在冗余，安全的环境中，它们也足够便宜，以至于不必考虑它们是荒谬的。

至于您的登记频率，通常是个人政策问题。在我自己的七人编码团队中，我倾向于每张工作票一次办理登机手续，而一位同事平均每天办理六次办理登机手续。

这真的是你很满意的事情。唯一的官方政策是：不要打破构建，不要破坏工作功能。如果您可能需要在中途交出工作，请更频繁地办理登机手续。这对我们有用。

Answer 7

我经常办理登机手续。

源代码管理有两件事情可以让您在不办理登记手续时输掉：

• 简化协作
• 跟踪随时间变化的历史记录

其他开发人员需要了解代码库中发生的更改。尽早签入您的更改会通知他们您正在处理的工作。它可以帮助防止重复工作（多个人实现相同的修复相同的bug）。不频繁的签入可能会导致代码发生重大且意外的更改，这更有可能导致调试困难（因为您刚刚签入的代码更少，但由于它与系统其他部分交互的复杂性） ）。

如果源控制系统不知道所做的更改，则无法帮助您还原更改。此外，如果你失去了过去一周你一直在努力的局部变化，那么伤害会更大。

您不应因磁盘空间而限制自己。 SCM系统非常了解其磁盘使用情况，但无论如何，存储都很便宜且充足。

那就是说，我建议你将你必须做的工作分成小块，并在完成一件这样的工作后办理登机手续。对你和其他开发者来说会更容易。

Answer 8

检查源代码的频率实际上是几件事情的功能，最值得注意的是文化和流程。您可能希望通过频繁登记来观察良好的“卫生”，以尽量减少数据丢失的风险，但这种做法还有其他好处，可能会根据您的方法或多或少地适用：

• 在敏捷的环境中，定期 签到降低构建风险 打破或遇到合并 冲突与其他程序员;

• 更频繁的签到意味着更多 细粒度的签到，这意味着你 收集更多 信息 ---这对你有用 获得有关项目健康状况的统计数据 寻找虫子;

• 粒状 签到是指办理登机手续的评论 更专注，而且更少 描述变化的可能性 已经制作;

• 精细签到 确保版本间差异 变得更容易导航。

您的具体问题是关于登记入住标准 ---这当然是一种风格问题。根据经验，我的目标是将任务分解为1到3个小时的子任务，每个子任务都有一个特定的目标 - 一旦你完成了一个子任务就办理登机手续。 “完成”是主观的，但在我的书中，它意味着工作，即所有单元测试都通过，并且您的代码覆盖率处于可接受的水平（您可以接受）。

Answer 9

问题：您使用的是哪种VCS？当您在度假时离开代码时，您的老板抱怨的评论似乎很奇怪。我总是使用Subversion签出代码，没人关心。

如果您使用需要保留签出的VCS，或者您需要伪造保留的签出，则您无法使用最佳做法，并且您的组织应升级到Subversion或更好。

这可能不适合您，但如果您使用的是古董VCS，则可能会影响给出的答案。

Answer 10

我同意这里所说的大部分内容，但我要补充一点，即如果你使用像bzr或git这样的分布式vc，那么对中央仓库进行频繁检查并不重要。在这种情况下，只要您只是更新本地存储库，您还可以向未经测试的提交倾斜一点。如果您因为不必担心影响其他人的任何问题而即使您尚未进行测试，那么即使您正在进行即将开始并提交也很方便。

Answer 11

您应该只签入有效且无法破坏构建的代码，您不应该尝试检查所有代码，以便为给定的功能创建一个可管理的更改集（假设您的版本控制系统支持更改集）概念）。

我不确定你对磁盘空间或搜索能力的意思。

Answer 12

这是我们使用的程序：

• 开发人员使用描述新功能或错误修复的设计文档获取任务。
• 开发人员进行这些更改并对其进行测试。
• 新代码由至少2位其他开发人员进行同行评审，确保设计文档中描述的功能和错误已得到实施或修复。
• 代码审核人员建议进行任何更改。如有必要，将进行另一次审查。
• 当审稿人满意，并且主管开发人员给出了OK时，开发人员对存储库进行“控制”（程序上 - 没有其他人可以检查任何内容，直到控制权被释放），检查更改，检查出应用程序的新副本以及它仍然构建并成功运行的编译和测试。

这意味着开发人员提交之间可能需要几周，有时甚至几个月，但这为我们提供了很多保护，可以防止破坏构建，并允许我们密切跟踪任务和与每个任务相关的更改。