Version control 如何保护主干不受开发人员的攻击

我们将TFS用于代码：主干+分支用于编码活动。我的团队中有6名开发人员

问题：有时开发人员不想创建新分支（或使用旧分支）来修复/开发某些东西。他们只是在后备箱里做。好的，在某些情况下是可以接受的。但大多数时候，它会制造很多麻烦

如何加强主干保护并强制开发人员创建新分支或重用旧分支

---

UPD：我不想给主干上的开发者提供只读访问权限（他们必须能够创建分支并自己将它们合并回来）。我想要一些折衷方案-可以创建分支/进行合并，但不能在主干中开发

您可以在TFS中创建用户组，以提供只读或完全没有访问权限。如果在团队项目上单击鼠标右键并单击“组成员资格”，然后将这些组添加到源代码管理资源管理器中的文件夹结构中。

直接处理主干几乎总是不正确的。是的，有时这可能是最有效的方法，但破坏过程就是破坏过程，最终会咬到你

我认为这个问题最好通过教育来解决，但是限制高级开发人员的主干写访问权也可能会有所帮助——如果他们没有被“感染”的话：）

---

Wortyh请记住，任何好的源代码存储库（读：而不是VSS）都可以避免您在这方面遇到终端问题，但这只是一个努力和关注的问题。您永远不想依赖回滚，只需说“不要惊慌”。

您可以在文件夹级别设置权限

创建分支是一个强大的权限。您可能需要一个人创建分支，然后设置权限

---

有关设置权限的信息，请参阅：

我将支持@annakata所说的内容。此外，我强烈建议您的组织中负责管理SCM的人员设置签入警报，以便在有人将代码签入主干时让您知道。这样，您就可以与负责的开发人员跟进（如有必要，使用前面提到的板球球拍）

需要考虑的其他一些技巧：

• 只允许高级开发人员签入。开发人员搁置他们的更改，高级开发人员审查然后签入。他们可以帮你把关

• 使用TFS2010的门控签入功能可以帮助您。打开行李箱的门控签入

• 以开发人员能够理解的形式进行教育。让他们确切地知道为什么在树干上建房是件坏事。SCM流程教育可以在很大程度上促使人们遵守。如果他们认为这只是一个武断的规则，他们不会因为违反它而感到难过

• 增加后果（组织允许的程度）。比如，当他们搞砸的时候，他们需要为啤酒/比萨饼基金捐款，或者需要戴一顶滑稽的帽子，甚至当有人登记到trunk时，向整个开发组织大声宣布。它很快就把重点讲清楚了

---

TFS是否像subversion一样支持运行钩子脚本

如果有，您可以运行提交前和提交后检查，查看提交是否遵循流程指南，拒绝补丁，并通过电子邮件解释原因等

如果这项工作太多，我最好的建议是与人们交谈，并对遵守规则的人给予良好的奖励，对违反规则的人给予惩罚。

他们对后备箱进行了什么样的“修复”？通常，您不应该签入到主干，而应该只合并

如果他们有增强功能或bug修复，可以等待，并且不是紧急情况，那么他们应该在开发分支中进行开发

如果是紧急情况，则从主干分支并进行热修复分支。这将是正在生产的产品的副本

您希望何时使用修补程序的示例：

---

假设您想要对生产或QA进行更改，但您不希望在DEV中完成的未来工作因为它对QA环境有破坏性的更改而停止，或者您只希望尽可能安全，并确保只有您知道要更改的代码与部署一起停止。如果您没有热修复程序分支，请单击主干并选择“分支”，然后将其命名为热修复程序或对您有意义的名称。然后在修补程序中进行更改，签入它们，并从修补程序分支部署。热修复程序将只包含两个内容：A.主干中的内容和B.您的一次性更改。它将不包括您尚未从DEV分支验证或测试的所有额外工作，这是一件好事

这是+1。这里需要的是教育（以及明智的板球击球），我完全反对只读访问，因为它使具有写访问权限的人成为合并的瓶颈。即使“被选中的人”反应迅速，这也是一个心理问题。设置警报并学会有效沟通。一个6人的团队不需要增加障碍或封锁。@Ryan Cromwell:完全同意，这是一个核选项：即最后的手段，意味着你已经失败了。