执行源代码管理

Question

如何设置一些组策略规则或机制以确保每个开发人员将其代码提交给源代码控制？

我将visualsvn服务器与Ankhsvn客户端btw一起使用。

由于

Answer 1

我们的基本政策是“如果它不在源代码库中则不存在。”

• 开发人员只有在签入代码时才能将任务标记为“开发完成”。
• 仅从标记的源代码集（而不是一些小丑的工作站副本）构建您的可交付成果。
不在源代码管理中的
• NOTHING 会进入质量保证或生产。

检查破损的代码被认为是不好的形式，但不会受到惩罚（除了那些不方便之外的一点点。）

我想使用持续集成并配置已损坏的版本来自动撤消损坏的更改，但我不希望能够在任何时候很快就能到达。

编辑：我们还需要在每个签到的评论中使用工件编号。这可以防止与要求无关的无偿更改。

Answer 2

这些政策最好使用同伴压力来实施。创建一个环境，在该环境中提交代码是公认的做法。否则，它将成为一种苦差事，开发人员会找到解决方法。

Answer 3

我认为实施源代码管理的最佳方法是在团队中构建一个结构良好的“软件开发文化”。

熟悉源代码管理优势的开发人员会毫不犹豫地使用它。

推荐文章：

• Check In Early, Check In Often

Answer 4

持续集成服务器可能有助于鼓励人们检查他们的代码。如果每个人都参与检查夜间构建/单元测试运行的代码，我想每个人都会开始看到好处。我同意以前的答案，强迫人们办理登机手续可能不是最好的方法 - 鼓励这种行为可能会更好地使用会使团队受益的事情。

Answer 5

向每个人发送电子邮件并告诉他们使用Source Control或被解雇！我不是一个告诉人们发出威胁甚至没有多少政策的人，但是使用源代码控制只是人们应该毫无疑问地加入的那些东西。

如果人们对源代码控制并不认真，那么有两种可能性。 1）设置太难了，你应该简化过程，使其成为一个一步到位的过程.2）他们是糟糕的开发人员，需要去。期！

Answer 6

这看起来真是个糟糕的主意。你能解释一下为什么要强行办理登机手续吗？

强制签入将导致破坏的构建和错误代码的传播。只有在代码处于运行状态且用户有时间查看所有更改时才能签入。开发人员应该可以自由地检查一些内容，进行实验并丢弃他们的更改。当我查看较旧的版本时，我会一直这样做。

如果您正在寻找的是强制备份，我会考虑除源代码控制之外的其他解决方案。

Answer 7

如果您经常与团队会面（例如每日SCRUM）并使用某种工具，例如我们Jira或Mantis或Rally，您可以在SVN系统中设置一个触发器来链接每个提交任务（或者甚至更好，一个带有任务的分支，但不幸的是，这对SVN来说不是那么好），您可以轻松检查开发人员是否已签入此任务的代码。大多数与问题/错误跟踪系统的集成都会在提交中修改文件，因此检查起来非常容易。

这不是强迫，但它会帮助您强制所有团队遵循之前提到的规则：提前签入，经常签到。