源代码控制：角色和职责-最佳实践

我正在寻找有关角色和职责的“最佳实践”，特别是谁负责从开发分支到主干（或主干）的合并。基本上，我正在寻找弹药来帮助我的事业。

让我描述一下我所面对的。我是特定应用程序的首席开发人员（所有者）。我们公司最近从VSS（我是存储我的应用程序的VSS数据库的管理员）转移到TFS（在这里我仅对“运营”团队创建的开发分支拥有权限）。在以前的工作中，我是TFS管理员，所以我了解TFS和MSBuild的使用方法。

我对使用的分支和合并策略没有任何问题（主分支，根据需要创建了错误/项目开发分支，然后合并回main，然后提升为发布分支）。我遇到的问题是：

1. 我无法创建自己的分支。我必须创建一个TFS任务，以使“操作”团队成员为我创建分支。

2. 我无法从Main合并到开发分支。我必须创建一个TFS任务，以使一个“操作”团队成员执行合并，然后希望他不要“踩”我的任何团队变更，因为“运维人员”可能是开发人员，也可能不是开发人员几乎不了解他正在合并的代码。

3. 我不能从开发合并到Main。同样，我必须创建一个TFS任务，以使“操作员”执行合并，希望他能正确执行。然后，我必须创建另一个TFS任务以合并回到我的分支，以便我可以解决由于非开发人员合并到Main而发生的任何问题。

4. 我无法创建或编辑MSBuild脚本。再次，我必须与MSBuild的“ ops”团队合作，以便只能执行最基本的构建任务。（忘记任何复杂的事情，或者天堂般的自定义任务）。

5. 我无法执行MSBuild脚本。同样，只有“ ops”团队可以做到这一点。

6. 最重要的是，通常是一个“离岸”资源来执行所请求的任务，因此，即使我在清晨创建任务（分支/合并/构建），它也可能不会完成直到那天晚上。

现在，“操作”团队维护发布分支没有问题。他们所做的（基本上）是从Main那里获取最新版本并将其升级到release分支；因此只要“ Main”稳定且准备就绪，发布分支就可以了。

我的意见是，技术主管（例如I）应负责维护主干（“主”）以及与开发分支之间的任何合并。团队负责人还应具有生成MS Build脚本以构建和部署到Integration测试环境的能力。

任何人都可以将我定向到可以帮助我证明自己情况的最佳做法文档吗？我所有的搜索只发现了有关分支和合并技术的最佳实践，没有提到WHO应该执行上述分支/合并。

我对最佳实践的一般看法是，假设这些操作没有完成生产部署之类的工作，那么开发团队的任何成员都应该能够在树上执行任何操作。如果某个特定的分支机构/标记/存储库确实充当自动化部署的来源，则需要进行一些合理的变更控制或进入障碍才有意义，那么从保持错误角度出发，更多的是错误而不仅仅是错误，而不是某些控制狂。我鼓励开发人员创建分支并改进构建脚本。如果需要，我会找到让开发人员访问生产的方法。源代码控制的一部分在于，它是一种有效的消除错误的魔术工具-您需要做的最坏的事情就是回滚一两个版本，然后分拆掉。

不幸的是，这听起来不像他们在这里采取的方法。为了克服这个问题，我认为您需要涵盖几个角度：

a）证明这些政策对发展事物有害。记录您在等待操作上花费的所有时间，以开始做某事。仅此一项就应该卖出合理的管理方法，以说明为什么这是一个糟糕的政策。

b）在Ops中结交一些朋友-也许有此政策的原因。也许可以更有效地解决这种推理。

希望这可以帮助。

我见过的做法是：

1. 任何人都可以根据自己的意愿创建工作分支。开发人员必须能够在发现第二步时创建功能分支，以便存储当前正在进行的工作。因为他们想/应该在一天结束时备份它，想与其他团队成员共享它，所以需要避免主体或其他方面的变化。

2. 任何人都可以对开发部门做任何事情。开发人员必须能够在另一个开发人员告诉他们他们需要的东西已经集成到main中的那一刻就与main合并。

3. 对于合并到主（集成），有三个选项：

   • 开发人员自己做。他们只是与主要开发人员讨论风险并适当地测试功能。这意味着任何人都有权限；如果有人违反了规则，他们就会被责骂，而错误的更改将被恢复。
   • 另一位开发人员在检查了更改之后进行了此操作。仍然需要每个人都有权限去做。规则仍由主要开发人员执行。
   • 有指定的集成商，负责审阅并合并到主要人员。但是集成商是团队的一部分，需要了解代码。在较小的团队中，它与建筑师是同一个人；在较大的团队中，它们是分开的，但需要紧密合作。

4. 谁准备了功能，谁都应该修改构建脚本。但是我不确定它如何与TFS一起使用；在我使用的系统中，构建脚本始终只是一个版本化文件，因此开发人员像对其他任何文件一样对其进行编辑，并将其与其他所有内容集成在一起。

5. 如果有指定的集成商，他们通常会负责定义（运行哪个脚本）并开始构建。否则，要么由团队负责人执行，要么由指定的团队成员执行，要么任何人都具有权限，并且团队负责人代表根据具体情况设置和启动特定构建。

6. 在任何情况下，以上操作均不要求团队外部的操作员。仅需要操作员才能设置权限，创建副本等。

别管“最佳实践”（与我同在），这是一个管理问题-基本上，由于受到约束，您无法正常工作。

什么是“最佳实践”实际上并不重要-这是一个简单，可证明的问题，它将影响您和您的团队的生产力，因此您需要在此基础上与生产线管理人员接洽。

我可以看到挥舞最佳实践文档可能（但仅可能）有助于说服他们，但更好的想法是，您必须让开发团队成员坐在他们的手上，同时等待其他时区的人除非流程得到改善/合理化，否则他们无法团结起来。

而且不要太具对抗性-就像您想知道限制为什么到位的任何事情一样，有什么正当理由...