如何保护主干免受开发人员的侵害
我们的代码使用 TFS：主干 + 分支用于编码活动。我的团队中有 6 名开发人员。
问题：有时开发人员不想创建新分支（或使用旧分支）来修复/开发某些内容。他们只是在后备箱里做。好吧，在某些情况下这是可以接受的。但大多数时候，它会带来很多麻烦。
如何加强对主干的保护并强制开发人员创建新的或重用旧的分支？
UPD：我不想向主干上的开发人员授予只读访问权限（他们必须能够创建分支并自行合并回来）。我想要一些妥协 - 可以创建分支/进行合并，但不能在主干中开发。
We are using TFS for our code: trunk + branches for coding activities. There are 6 devs in my team.
Problem: sometimes developers don't want to create a new branch (or use an old one) to fix/develop something. They just do it in trunk. OK, in some cases it's acceptable. But most of the time it creates a lot of troubles.
How can I enforce protection of trunk and force devs to create new or reuse old branches?
UPD: I don't want to give read-only access to the devs on trunk (they have to be able to create branches and merge them back by themselves). I want some compromise - can create branches/do merging but can't develop in the trunk.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您可以在 TFS 中创建用户组以提供只读或根本没有访问权限。如果您在团队项目上单击鼠标右键并单击组成员身份，则将这些组添加到源代码管理资源管理器中的文件夹结构中。
You can create user group within TFS to give readonly or no acess at all. If you right mouse click over the team project and click group membership, then add those groups to the folder structure in the source control Explorer.
他们对 TRUNK 做了什么样的“修复”？通常，您永远不应该签入 TRUNK，而只能合并...
如果他们有可以等待的增强或错误修复，并且不是紧急情况，他们应该在开发分支。
如果是紧急情况，则从 TRUNK 分支出来并创建一个 HOTFIX 分支。这将是正在生产的内容的副本。
您想要使用 HOTFIX 的情况示例：
假设您想要对生产或 QA 进行更改，但您不希望在 DEV 中完成的未来工作立即完成，因为它对 QA 环境进行了重大更改，或者您可能只是想确保安全可能并确保只有您知道要更改的代码随您的部署而变化。如果您没有 HOTFIX 分支，请单击 TRUNK 并选择“分支”并将其命名为 HOTFIX 或对您有意义的名称。然后在 HOTFIX 中进行更改、签入并从 HOTFIX 分支进行部署。 HOTFIX 将仅包含两件事，然后 A. TRUNK 中的内容和 B. 您的一次性更改。它不会包括您尚未从 DEV 分支验证或测试的所有额外工作，这是一件好事。
What kind of "fixes" are they making to the TRUNK? Typically you should never check-in to TRUNK but only merge...
If they have enhancements or bug fixes that can wait and that are not emergencies they should do their development in the DEV branch.
If it is an emergency then branch off of TRUNK and make a HOTFIX branch. This will be a copy of what is in production.
Example of when you would want to use HOTFIX:
Let's say you have a change you want to make to production or QA but you don't want the future work done in DEV to go out just yet as it has breaking changes for the QA environment or maybe you just want to be as safe as possible and make sure only the code you know you wanted to change went out with your deployment. If you do not have a HOTFIX branch then click on TRUNK and select "Branch" and name it HOTFIX or something meaningful to you. Then make your changes in HOTFIX, check them in, and deploy from the HOTFIX branch. The HOTFIX will only contain two things then A. What is in TRUNK and B. Your one-off changes. It will not include all of the extra work that you haven't validated or tested from the DEV branch, which is a good thing.
TFS 是否支持像 subversion 那样运行钩子脚本？
如果有的话，你可以运行提交前和提交后检查，看看提交是否遵循流程指南，拒绝补丁并通过电子邮件解释原因等。
如果这工作量太大，我最好的建议是与人们交谈，并使用良好的旧奖励来遵守规则和违反规则的惩罚。
Does TFS has support for running hook scripts like subversion has?
If it has you can run pre-commit and post-commit checks to see if commits follows process guidelines, reject patches with an email explaining why etc.
If thats too much work my best advice is talking to people and use good old reward for adhering to rules and punishment for breaking them.
我会附议@annakata 所说的。此外，我强烈建议组织中负责管理 SCM 的人员设置签入警报，让您知道有人将代码签入主干。这样，您就可以与负责的开发人员跟进（如有必要，使用前面提到的板球棒）。
需要考虑的其他一些技术：
仅允许高级开发人员签入。开发人员搁置他们的更改，高级开发人员审查然后签入。他们可以帮助成为您的看门人。
使用 TFS2010 的门控签入功能来帮助您。打开中继的门控签入。
以开发人员可以理解的形式进行教育。让他们确切地知道为什么建立主干是一件坏事。 SCM 流程教育对于让人们遵守有很大帮助。如果他们认为这只是一个任意规则，他们不会因为违反它而感到难过。
添加后果（无论您的组织允许什么程度）。比如，当他们搞砸时需要为啤酒/披萨基金做出贡献，或者需要戴上一顶有趣的帽子，甚至当有人签到后备箱时向整个开发组织大声宣布。它可以快速传达要点。
I'll second what @annakata said. Additionally, I highly recommend that whomever is responsible for managing SCM in your organization to set up a check-in alert that lets you know when someone checks code into the trunk. That way, you can follow up (with the previously-mentioned cricket bat, if necessary) with the developer responsible.
Some other techniques to consider:
Only allow senior developers to check in. Developers shelve their changes, and the senior devs review then check-in. They can help be your gatekeeper.
Use the gated-check-in feature of TFS2010 to help you. Turn on gated check-ins for the trunk.
Education in a form that developers can understand. Make them know exactly why building off the trunk is a bad thing. SCM process education can go a long way to getting people to comply. If they think it's just an arbitrary rule, they don't feel bad about violating it.
Add consequences (to whatever degree your organization allows). Things like a beer/pizza fund that they need to contribute to when they screw up, or a funny hat that needs to be worn, or even a loud announcement to the entire development organization when someone checks in to trunk. It gets the point across quickly.
您可以在文件夹级别设置权限。
创建分支是一个强大的权限。您可能需要一个人来创建分支并设置权限。
有关设置权限的信息，请参阅：http://msdn.microsoft.com/en -us/library/ms252587.aspx
You can set permissions at the folder level.
Creating a branch is a powerfull permission. You will probably have to have one person who creates the branches and then sets the permissions.
For information on setting permissions see: http://msdn.microsoft.com/en-us/library/ms252587.aspx
直接在树干上工作几乎总是不正确的。是的，有时这可能是最有效的方法，但破坏过程就是破坏过程，最终会咬住你。
我认为这个问题最好通过教育来解决，但是限制高级开发人员的主干写入权限也可能有所帮助 - 如果他们也没有“感染”:)
值得记住的是，任何好的源存储库（阅读：不是 VSS）将使您免受这方面的终端问题的困扰，这只是一个努力和警惕的问题。你永远不想依赖回滚，只是说“不要惊慌”。
Working on the trunk directly is almost always incorrect. Yes it can be the most efficient way sometimes, but breaking process is breaking process and that will bite you eventually.
I think this problem is best solved with education, but limiting trunk write access to senior devs might help too - if they aren't "infected" too :)
Wortyh bearing in mind though that any good source-repository (read: not VSS) will save you from terminal problems in this area, it's just a matter of effort and watchfulness. You never want to rely on rollbacks, just saying "don't panic".