版本控制应考虑哪些签入策略？

我的任务是帮助为我公司的TFS 2008安装设置流程模板和签入策略。版本控制应考虑哪些签入策略？

除了三项签到政策（签入行为必须有评论意见，代码文件必须经过同行评审，必须有与签入相关的工作项），我被问到考虑和实施任何其他。

什么是一些最重要或有用的策略来执行版本控制？

来源

2009-07-29 Phil.Wheeler

同行评审不一定是签入的先决条件。您可以先登记，同行审查已提交的文件，然后在审查后将文件提交给另一个分支。 – Dan 2009-07-29 03:07:39

越少越好。

通常在一个组织中，您希望缓解签入的摩擦，以确保您鼓励开发人员频繁进行小型离散签入，而不是一次签出一堆东西。然后，再次，您要确保为每个需要它的人提供有效的代码库，并捕获您需要改进软件交付流程的数据。

就个人而言，执行变更集注释和工作项关联策略的策略是可以的 - 因为它们捕获当时非常容易记住，但之后很难找到的元数据。它还鼓励开发人员养成有工作项目来跟踪所有工作的习惯 - 即使是实验开发或尖峰。

使用分支或其他过程可能会更好地执行同行评审过程，而不是强制每次签到同行评审 - 但这取决于您的过程。还要记住，您可以在TFS中使用强制签入注释来捕获代码审阅者等元数据。办理入住手续的注意事项与入住政策略有不同，且经常混淆。

如果您想了解更多有关签入政策的讨论，请查看blog post I did on the balancing act a while ago。此外，为了听取更多有关签到政策的讨论，我最近与一位Team System MVP同事谈论了他们使用TFS的情况，并记录了一个播客，这可能很有趣（Radio TFS, Using TFS with Ed Blankenship）。最后，我们还在2008年做了一个Radio TFS episode all about check-in policies，这可能是有趣的。

来源

2009-07-29 08:48:54

，我们按照我们公司的一些规则：

提交一次有关同一任务的所有变化（这将有助于审查变化和今后的回滚或者如果需要合并）。
基于模板的注释（例如：前缀所有注释的代码代表所做的事情，+添加， - 删除，*更新，！重要修改等）。
显然总是签入代码编译，并完成工作的主线。
办理每日未完成的工作到分支机构。

来源

2009-07-29 02:41:54

我不认为“原子提交”意味着你认为它的作用。这是VCS的一项功能（不是），而不是团队策略。我认为你的意思是“一次签入所有与同一变更相关的文件”。 – 2009-07-29 02:59:37

你是对的，但我们在我们公司中这样说。 – 2009-07-29 03:01:05

不要打破构建！当然，找到一种自动化的方法来检查并拒绝签入是挑战。

来源

2009-07-29 02:41:57 JustJeff

这是一个非常微不足道的。另外我认为自动检查来源不是政策本身，它更多是一种控制机制或确保政策得到遵守，在这种情况下，始终签入可建立的政策。 – 2009-07-29 03:26:46

坦率地说，政策越少越好。您拥有的政策越多，不使用版本控制的动机就越大。然后会发生什么：

代码是在并行的，不受控制的源代码控制系统上开发的，只是最终的修订版本转向官方版本。
人们尽可能延迟提交，降低了他们对其他开发人员的可见性。
人们实际上可以避免承诺一些事情，如果他们能够避开它，有些人会找到一种方法来摆脱它。

实际上，我认为您的三项登记政策已经太多了。例如：

让代码在签入之前进行同行评审使得在此存储正在进行的工作更加困难。相反，如果源代码管理系统允许（和许多）控制源代码是否经过同行评审。对于某些系统，您可以为修订创建生命周期，其他人可以创建分支，还有一些系统可以使用标记。
让工作项目与签入相关联使得开发人员无法进行探索性编程，或对可能的改进有主动性。它扼杀了开发者。相反，确保进入集成测试或用户验收测试的任何修订，更不用说生产本身，与工作项目相关联。

这可能听起来反对企业，但它只是我们在几十年的软件开发中学到的一些东西。大多数企业组织都没有涉及到这一点，但最终他们会这样做。所以，你可能会走相反的道路，但不要说没有人告诉过你。

我推荐Agile Manifest，特别是Lean Software Development的一般原则。或者，考虑到Stack Overflow设计理念，让系统奖励您想要的行为。

来源

2009-07-29 02:55:15

善用风险投资系统是开发者作为团队成员的责任的关键部分，无论政策，政策是否按照相同的方式进行使用，如编码指南（您认为它们也是无用的？），在我的公司，VC准则是编码准则的一部分。 – 2009-07-29 03:23:03

@Lucas S.无用？在我使用“无用”一词或其任何同义词的地方，我的整个答案中是否有任何地方？我没看到它。把它指向我，我会把它击倒！良好地使用VC系统对软件开发至关重要，这就是我提倡不让人们避免使用它的原因。至于“开发人员责任”和“团队合作伙伴”，这是通过领导和管理在开发人员中产生的东西。这不是违反不合理政策并假定他们会工作的借口。 – 2009-07-29 03:43:26

TFS中还有Shelve功能。这使您可以有效地创建迷你开发者分支和他们的工作代码。 – 2009-07-30 12:32:17

尽量减少在同一分支上工作的开发人员数量。这样分支在编译，单元测试和回归方面保持稳定。如果开发人员进行编译检查，但他的代码打破了应用程序的关键区域（如登录），这是一场噩梦。

如果您确实需要10多位开发人员将代码检入同一分支，我们已经启动了一个电子邮件策略，开发人员检查警告所有人他们正在签入，以免任何人尝试更新他们分支机构在办理入住手续时的副本。有时候，我们必须有相反的地方，我们在该日期留出一段时间禁止入住，以便更新安全。

来源

2009-07-29 03:04:38 Alan

我们所使用的那些，我对TFS工作是：

代码分析
- 这将确保所有的代码是在开发者机器上编译它在
工作项目协会
- 如果您已经做了更改，应该有一个分配任务！
最后成功打造
- 使用TFS构建服务器来检查，在源代码控制当前代码一个独立的机器上编译
入住注释（TFS电动工具的一部分 - http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx ）
- 很高兴能够看到检查概要，而无需转到工作项目

来源

2009-07-29 03:07:23

版本控制应考虑哪些签入策略？

回答

相关问题