SVN提交规则

仅当解决方案成功编译和生成时，才应进行提交吗？“中途”提交是否可以接受在非常大的更改中导致代码在几个小时内无法工作？

是的，它是可以接受的

版本控制用于版本控制；不是备份。您应该为处理可编译代码的备份准备一些单独的东西，这些代码实际上可能会返回到版本控制系统

---

无论哪种方式，强迫开发人员等待签入代码都是一场即将发生的代码丢失灾难

确保代码不会被破坏太久是我们的工作，而不是版本控制。

除了Brian和Aaron的评论，我只想补充一点，即使是稳定性和最新代码之间的这种折衷，也可以通过使用分支或像Git这样的分散系统（作为一种更极端的解决方案）来缓解。“经常提交并让构建机器人发现错误”是我最喜欢的策略，但是如果您需要一个更稳定的地方来签出代码，那么分支就是您想要的（当然必须有人维护它）。

在我看来，这取决于所使用的VCS类型：

• 如果您使用的是像SVN这样的集中式，我倾向于说是的，下面的参数是可以接受的
• 如果您运行的是类似Git的DVCS，我会说不，这是不可接受的，因为每个开发人员都可以进行本地提交，测试实现，然后在完成工作后返回（裸）公共回购

---

既然您已将问题标记为svn，请遵循。

根据我的经验，至少不要提交破坏性的更改，这一点很重要。如果团队规模更大，或者开发速度更快，情况就更糟了。这个想法是团队的所有成员都要跟上最新的变化任何人都不应该害怕在团队成员每次提交后执行

svn更新

如果最新版本经常有编译错误，这是不可能的。即使是失败的测试也会让人恼火，因为要判断问题是由未提交的更改引起的，还是由

svn更新

刚刚收到的更改引起的，并不总是那么容易。当每个人都试图弄明白为什么事情突然停止运转时，工作陷入停顿

破坏性的改变也会影响你的工作能力。因此，即使您单独或在功能分支上工作，避免它们仍然是有价值的

避免破坏更改的策略不必与常规的小提交相矛盾。大的更改几乎总是可以被分成一系列较小的任务，每个任务都可以通过一个不破坏构建的适度规模的提交来完成。这样做的另一个好处是减少了冲突。对于较小的任务，我倾向于在提交消息中添加以下内容：

• 修复xyz：方面foo准备中的重构模糊
• 修复xyz：方面foo现在可以工作了
• 修复了xyz：方面栏现在可以工作了

---

+我同意。尽可能多地承诺。别想太多。尽你所能去做。我发现经常承诺只有好处，没有坏处。我也同意。你不希望开发人员在山洞里进行开发，然后一边说“祝你玩得开心！”一边向其他程序员扔一堆比特和字节。我在一家公司工作，如果你损失了超过一天的时间或工作（病毒、硬盘崩溃、笔记本电脑被盗等），这要视情况和其他因素而定，这可能是一种可以开火的进攻。@jgifford25 Eee-yikes！！希望你的压力得到了很好的补偿…我想我会发疯的担心…对+1.如果你担心太频繁的提交会破坏太多的东西，那么就换成git之类的东西，或者让每个开发人员在编译东西时使用单独的分支并合并到主干上，正如@Luke Maurer所建议的那样。我不同意Dave的观点，提交不是保存功能。我更喜欢在我完成编码后提交，我可以给提交写一些很酷的评论（如果你把它用作保存，你就不会写提交），即使你的公司不相信CI，你也可以把它放在你的一台机器上（这只是JEE的一场战争，不会让你慢下来）.如果您的公司控制异常，要求trunk始终编译，CI应该是他们的湿梦…它强制trunk可以编译，并在几分钟内找到罪犯…我认为问题在于制定政策（例如，“您不应进行破坏性更改”），我不想从技术上强化这一政策。我向我的团队成员推荐这种方法。它消除了破坏构建的恐惧（因为功能分支通常不会自动构建），同时还提供了在存储库中进行更改的安全性。它还帮助我的团队学习如何更好地合并他们的代码，因为我鼓励他们重新整合自己的功能分支。@arcain您在使用SVN内置的合并管理吗？那效果如何？我这样问是因为几个月前我们被一个混乱的功能合并烧坏了，因为我们运行的是一个旧的SVN版本，所以我们一直在手工整理它。我们使用的是TortoiseSVN，我从来没有因为错误而导致合并失败过，但我们也遇到过提交者操作错误的案例，其中对分支的意外提交只需要回滚一些修改。自动重新整合分支不是一个选项，因为完整的修订范围无法合并回父级，所以我们必须选择修订范围。在某些情况下，忽略合并到分支的工作副本中的rev，将冲突标记为已解决，然后手动合并更改就更容易了。