加强源头控制
如何设置一些组策略规则或机制来确保每个开发人员都将其代码提交到源代码管理？
我使用 Visualsvn 服务器和 Ankhsvn 客户端顺便说一句。
谢谢
How do I set some group policy rule or mechanism to make sure that every developer commits their code to the source control?
I use visualsvn server with Ankhsvn client btw.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
这看起来确实是个坏主意。 您能解释一下为什么要强制签到吗？
强制签入将导致构建中断和错误代码的传播。 仅当代码处于运行状态并且用户有时间查看所有更改时才应进行签入。 开发人员应该可以自由地检查某些内容、进行试验并放弃他们的更改。 当我查看旧版本时，我总是这样做。
如果您正在寻找的是强制备份，我会考虑除源代码控制之外的其他解决方案。
This really seems like a bad idea. Could you explain why you want to force check-ins?
Forcing check-ins will lead to broken builds and propagation of bad code. Check-ins should only be done when the code is in a running state and the user has time to review all their changes. Developers should be free to check something out, experiment with it, and throw away their changes. I do this all the time when I check out older revisions.
If what you're looking for is a forced backup, I would consider some other solution besides source control.
如果您定期与团队会面（例如每日 SCRUM）并使用某种工具，例如 Jira 或 Mantis 或 Rally，并且您在 SVN 系统中设置一个触发器，将每个提交链接到任务（或者更好的是，一个带有任务的分支，但不幸的是，这对于 SVN 来说不太好），您可以轻松检查开发人员是否已将代码签入到该任务中。 大多数与问题/错误跟踪系统的集成都会创建一个包含提交中修改的文件的附件，因此非常容易检查。
这不是强迫，但它会帮助你强制所有团队都遵循前面提到的规则：尽早签到，经常签到。
If you meet regularly with the team (like daily SCRUMs) and use some sort of tool such us Jira or Mantis or Rally, and you set up a trigger in your SVN system to link each commit to a task (or even better, a branch with a task, but unfortunately this is not that good with SVN) you can easily check if developers have checked in code to this task. Most of the integrations with issue/bug tracking system create an attach with the files modified in the commit, so it will be really easy to check.
This is not forcing, but it will help you enforce that all team follows the rule mentioned before: checkin early, checkin often.
我们的基本政策是“如果它不在源代码存储库中，则它不存在。”
签入损坏的代码被认为是不好的形式，但不会受到惩罚（除了那些不便的人的一点嘲讽之外。）
我想使用持续集成并配置损坏的构建来自动取消损坏的更改，但我不希望能够到我现在所在的任何时间。
编辑：我们还要求每次签入的评论中包含工件编号。 这可以防止与需求无关的无端更改。
Our basic policy is "If it's not in the source code repository it doesn't exist."
Checking in broken code is considered bad form but is not punished (outside a little ribbing from those inconvenienced.)
I'd like to use continuous integration and configure broken builds to automatically back out the broken changes but I don't expect to be able to any time soon where I'm at.
Edit: We also require artifact numbers in the comment for each checkin. This prevents gratuitous changes that are unassociated with a requirement.
此类政策最好利用同侪压力来执行。 创建一个环境，使提交代码成为可接受的做法。 否则，这将成为一项苦差事，开发人员会找到解决方法。
These sort of policies are best enforced using peer pressure. Create an environment where it is the accepted practice to commit the code. Otherwise, it will become a drudgery and developers will find ways around it.
我认为实施源代码控制的最佳方法是在团队中建立良好的“软件开发文化”。
深知源代码控制优势的开发人员会毫不犹豫地使用它。
推荐文章：
I think that the best way to enforce source control is to build a well formed "Software Development Culture" on your team.
Developers that well know the benefits of source control, won't hesitate about using it.
Recommended article:
持续集成服务器可能有助于鼓励人们签入他们的代码。 如果每个人都参与检查代码以进行夜间构建/单元测试运行，我想每个人都会开始看到好处。 我同意之前的答案，即强迫人们签到可能不是最好的方法 - 最好是使用有利于团队的东西来鼓励这种行为。
A continuous integration server might help encourage people to check in their code. If everyone gets on board with checking in code for nightly builds/unit test runs, I think everyone will start to see the benefits. I agree with previous answers that forcing people to check in might not be the best approach - it's probably better to encourage that behavior using something that will benefit the group.
给每个人发电子邮件，告诉他们使用源代码管理，否则就会被解雇！ 我不是一个告诉人们发出威胁甚至制定许多政策的人，但使用源代码控制只是人们应该毫无疑问地接受的事情之一。
如果人们不认真对待源代码控制，那么有两种可能性。 1）设置太难了，你应该简化流程，使其成为一步完成的签入流程。2）他们是糟糕的开发人员，需要离开。 时期！
Email everyone and tell them to use Source Control or be fired! I'm not one to tell people to give out threats or even to have many policies, but using source control is just one those things that people should just be on board with without question.
If people are not serious about source control, then there are two possibilities. 1) The setup is too hard, and you should simplify the process to make it a one step process to check in. 2) They are bad developers and need to go. Period!