源代码控制：角色和职责-最佳实践
我正在寻找有关角色和职责的“最佳实践”，特别是谁负责从开发分支到主干（或主干）的合并。基本上，我正在寻找弹药来帮助我的事业。 让我描述一下我所面对的。我是特定应用程序的首席开发人员（所有者）。我们公司最近从VSS（我是存储我的应用程序的VSS数据库的管理员）转移到TFS（在这里我仅对“运营”团队创建的开发分支拥有权限）。在以前的工作中，我是TFS管理员，所以我了解TFS和MSBuild的使用方法。 我对使用的分支和合并策略没有任何问题（主分支，根据需要创建了错误/项目开发分支，然后合并回main，然后提升为发布分支）。我遇到的问题是： 我无法创建自己的分支。我必须创建一个TFS任务，以使“操作”团队成员为我创建分支。 我无法从Main合并到开发分支。我必须创建一个TFS任务，以使一个“操作”团队成员执行合并，然后希望他不要“踩”我的任何团队变更，因为“运维人员”可能是开发人员，也可能不是开发人员几乎不了解他正在合并的代码。 我不能从开发合并到Main。同样，我必须创建一个TFS任务，以使“操作员”执行合并，希望他能正确执行。然后，我必须创建另一个TFS任务以合并回到我的分支，以便我可以解决由于非开发人员合并到Main而发生的任何问题。 我无法创建或编辑MSBuild脚本。再次，我必须与MSBuild的“ ops”团队合作，以便只能执行最基本的构建任务。（忘记任何复杂的事情，或者天堂般的自定义任务）。 我无法执行MSBuild脚本。同样，只有“ ops”团队可以做到这一点。 最重要的是，通常是一个“离岸”资源来执行所请求的任务，因此，即使我在清晨创建任务（分支/合并/构建），它也可能不会完成直到那天晚上。 现在，“操作”团队维护发布分支没有问题。他们所做的（基本上）是从Main那里获取最新版本并将其升级到release分支；因此只要“ Main”稳定且准备就绪，发布分支就可以了。 我的意见是，技术主管（例如I）应负责维护主干（“主”）以及与开发分支之间的任何合并。团队负责人还应具有生成MS Build脚本以构建和部署到Integration测试环境的能力。 任何人都可以将我定向到可以帮助我证明自己情况的最佳做法文档吗？我所有的搜索只发现了有关分支和合并技术的最佳实践，没有提到WHO应该执行上述分支/合并。