SVN提交规定

Question

如果解决方案成功编译和构建，才应该提交吗？在非常大的更改中，代码在几个小时内无法工作，是否可以接受“中途”提交？

- bevacqua

Answer 1

是可以接受的。

版本控制用于版本控制，而不是备份。您应该另外安排备份编译代码的方案，这些备份可能确实会回到版本控制系统。

无论如何，强迫开发人员等待检入代码是一种即将发生丢失代码的灾难。

- Aaron McIver

---

+1。我同意。尽可能经常提交。不要想太多。尽可能多地提交。我发现经常提交只有好处，没有坏处。 - Upgradingdave

+1。我也同意。你不希望开发人员在一个洞穴里开发，然后把一堆比特和字节扔给其他程序员，说“玩得开心！”我曾在一家公司工作，如果你丢失了一天以上的工作（病毒、硬盘崩溃、笔记本电脑被盗等），根据情况和其他因素，可能会被解雇。 - jgifford25

没错，加一。如果你担心频繁提交会导致太多问题，可以切换到像 git 这样的工具，或者让每个开发人员使用单独的分支，在编译成功后合并到主干上，就像 @Luke Maurer 建议的那样。 - Brian Clapper

我不同意Dave的观点，commit并不是一个保存函数。我更喜欢在完成编码后进行提交，并为该提交编写酷炫的注释（如果您将其用作保存，则不需要编写提交）。 - IAdapter

@01 当然，提交并不等同于保存。提交应该是一个独立的、有凝聚力的工作单元（所谓的原子性问题）。这里的问题不在于提交的大小，而在于它上面的其他要求有多严格。我们认为，不破坏构建的重要性不如通常认为的那么重要。提交的理想大小是一个单独的（但相关的）问题。 - Luke Maurer

Answer 2

确保代码不会长时间处于损坏状态是持续集成的工作，而不是版本控制。

- Brian Clapper

---

即使你的公司不相信CI，你也可以将其放在其中一台机器上（这只是JEE中的一个war，不会拖慢你的速度）。 - IAdapter

如果你的公司控制欲强到要求主干总是编译通过，持续集成(CI)应该是他们的梦想...它能够强制主干编译通过并在几分钟内找出罪犯。 - Luke Maurer

我认为这个问题是关于制定策略（例如“不得提交破坏性更改”），而不是关于技术上对该策略的强化。 - Wim Coenen

Answer 3

除了Brian和Aaron的评论外，我只想补充一点，即即使在稳定性和最新代码之间存在这种权衡，也可以使用分支或更极端的解决方案，如Git这样的分散式系统来减轻这种权衡。 "经常提交并让构建机器人发现错误"是我的最爱策略，但如果您需要一个更稳定的代码检出位置，则需要一个分支（但当然有人必须维护它）。

- Luke Maurer

---

我向我的团队成员推荐这种方法。它可以消除破坏构建的恐惧（因为特性分支通常不会自动构建），同时也提供了在存储库中拥有更改的安全性。此外，它还可以帮助我的团队学习如何更好地合并他们的代码，因为我鼓励他们重新集成自己的特性分支。 - arcain

@arcain 你使用 SVN 内置的合并管理工具吗？它的效果如何？我问这个问题是因为几个月前我们被一个混乱的功能合并搞糟了，由于我们运行的是旧版本的 SVN，所以我们被迫手动解决。 - Luke Maurer

我们使用TortoiseSVN，我从未遇到过合并失败的错误，但我们曾经有过提交者的操作错误，导致意外提交到一个分支，需要回滚几个修订版本。自动重新集成该分支不是一个选项，因为无法将完整的修订范围合并回父级，所以我们必须挑选修订范围。在其中一些情况下，忽略从分支合并到工作副本的修订版本，标记冲突已解决，并手动合并更改只是更容易的方法。 - arcain

Answer 4

在我看来，这取决于所使用的版本控制系统类型：

- 如果你正在使用像SVN这样的集中式版本控制系统，我倾向于说是可以接受的，遵循Aaron的论点。 - 如果你正在运行像Git这样的DVCS，我会说不可接受，因为每个开发者都可以进行本地提交、测试实现，然后一旦完成工作就将其推回（裸）公共仓库。

由于你的问题标记了svn，请遵循Aaron的建议。

- eckes

Answer 5

在我的经验中，至少尝试着不要提交破坏性的更改是很重要的。如果团队规模较大或开发速度较快，则更为重要。这个想法是让团队的所有成员都跟上最新的变化。每个团队成员提交后都应该毫不犹豫地执行svn update。

如果最新版本经常出现编译错误，那么这是不可能的。即使测试失败也会很烦人，因为很难确定问题是由你未提交的更改引起的还是刚刚通过svn update接收到的更改引起的。当每个人都试图弄清楚为什么突然间事情不再工作时，工作就会停滞下来。

破坏性的更改也会干扰您对源代码历史进行二分查找的能力。因此，即使您是独自工作或在功能分支上工作，避免它们仍然很有价值。

避免破坏性更改的策略并不一定与经常进行小提交相矛盾。几乎总是可以将大更改拆分为一系列较小的任务，每个任务都可以通过适度大小的提交完成，而不会破坏构建。这样做的另一个好处是减少冲突。我倾向于在此类较小任务的提交消息中添加以下内容：

• 朝着修复xyz的方向：重构了fuzz以准备aspect foo
• 朝着修复xyz的方向：aspect foo现在可用
• 已修复xyz：aspect bar现在可用

- Wim Coenen