什么是大型任务的良好源代码管理检入策略？

一般规则是保持较小的登机手续并经常办理登机手续。但是有时任务需要对基础框架进行大的更改。然后在完成任务之前签入将中断项目，直到您签入完成的工作。

那么，人们使用什么策略来减少失去工作的风险，或者确定您正在做的事情是错误的方法，然后在删除代码并尝试另一种方法之后改变主意？

如果可以，我将签入已完成的工作的一半注释掉，或者如果它可以编译并且什么都没有使用，我将它们签入。更改越大，我越有可能分支该项目然后合并回去等我一切都恢复正常的时候 如果源控制系统允许，则另一个选择是架子集，它们基本上是小分支。因此，当我完成当天的工作或到达决策点时，我将搁置我的更改，然后，如果发生了灾难性的事情，或者我想回到那个点，我可以。

我使用git，所以我的答案是“分支”。完成各种操作后，分支并提交零食。

随心所欲地将提交推进到上游，这样您的同事就可以在不中断中继的情况下查看更改。

当每个人都对代码满意时，合并即可完成！

（对于比较长时间运行的分支，我倾向于定期将主干（git术语中的master）合并到我的分支中，因此这两个分支不会出现太大的分歧。）

我认为答案将根据您使用的是哪种版本控制系统而有所不同：集中式（例如Subversion）还是分布式（例如git）。我没有使用分布式源代码控制系统的任何现实经验，所以我的答案是基于我们对Subversion的处理。

如果正在进行的重大更改会在一段时间内破坏我们的主干构建，或者确实会以其他方式破坏团队的其他成员，那么我们将创建一个分支。我要说的是，尽管您应该尽一切可能避免这样做-大多数更改可以与其他代码并排放置，而无需付出任何努力。例如，您可以将代码路径触发到新代码中（使用简单的if语句，或者如果使用DI框架，则可以基于配置设置注入新版本）。然后，完成后，只需将配置更改为新版本，测试所有内容，删除未使用的代码，再次测试，最后删除配置设置。您不能总是这样做，但是由于维护分支的开销，我认为您应该始终检查是否可行。

如果您进行分支，我认为我经常看到的人犯的错误不是使他们的分支与主干保持最新。您应该不断地将主干中的更改合并到分支（如果存在）中，以便在完成所有内容的反向合并之后变得相当琐碎。

在外团队中，我们使用颠覆，通常我们会直接对主干进行少量更改。对于较大的任务，开发人员通常会创建一个私有分支，完成后将其合并到主干中。然后，删除专用分支。自然，私有分支存在时，其所有者应经常检查它。

我们尝试避免存在长期存在的分支和主干到分支的合并，因为这需要仔细记账。取而代之的是，我们有一些寿命相对较短的分支，这些分支仅合并回到主干一次，并在之后不久被删除。

而且我们有一条规则，在至少有其他人查看并批准更改之前，不得将任何内容提交或合并到中继。

就像SQL Server人们通常的评论一样，“取决于”

如果可以的话，我建议您在代码上创建一个分支，以便您可以继续应用工作的小型签入。完成后，执行合并回到主干中。

是的，这样做有可能会产生重复的努力。但是至少您会保留一些工作线索，可以回滚它，事实证明这是死胡同。