源代码管理最佳实践 - 定期从存储库更新工作副本

Question

（注意：这个问题不是特定于Subversion的 - 我只是在这里使用它作为例子。）

我知道“svn update”命令（或其他类似命令在其他系统中）将更新您的工作副本，并对存储库中的文件进行任何更改。我也知道，在源控制中最好的做法是定期执行svn更新，以确保在最终提交（签入）这些更改之前已经获得了最新的更改集。

这种最佳实践的替代方法（可能是最糟糕的做法：＆gt;）将在提交（签入）时间内仅管理 的潜在冲突，而不是在您正在编辑文件的期间。

似乎最好的做法是采用“悲观”方法尽早和经常地管理冲突，而不是仅在提交时管理冲突并在以后管理所有累积冲突的“乐观”方法。

我是否正确地说明了最佳做法与替代方案的意图？

Answer 1

我个人每天在开始工作时更新我的​​工作副本。我发现冲突很早就找到了，并且很快就解决了。

Answer 2

是的，悲观是好的。

更早，更小，更不全面的变化更容易

• A。 SVN的automerges（或TFS或其他）和
当人类必须解决冲突时，
• B 会更容易。

当然，这取决于相同代码中有多少其他开发人员以及他们使用您正在处理的模块的可能性。 （例如，我目前是唯一一个在我的项目中工作的人。我不像其他人在那里那样频繁刷新。）

Answer 3

正确的是，随着分布式版本控制方法的兴起，越来越多的人倾向于“变暗”，就像有人会说的那样，为了自己的东西而开始工作并担心以后合并它。

许多人，包括我自己，会说这会导致更多难以解决的冲突，因为您实际上是在不同的分支中运作，因此朝不同的方向发展。

定期更新确保您不会远离其他人的路径，但许多其他人认为这会破坏分布式版本控制的灵活性。

Answer 4

存在一些中间立场 - 您可以将更改保留在分支中，与正在进行的主干更改分开。这在git中非常容易，而且在颠覆中不太容易（我会说）。这可以让你做的是定期从trunk中提取更改，而不会自动“冒险”你的本地更改被与trunk提交冲突搞砸了。我认为，这是你不想想要提取更新的原因 - 也就是说，因为你还没有为他们做好准备。你会看到发生了变化，这是一件非常好的事情。在单独的分支上进行更改意味着您可以尝试合并上游更改，但如果它们不匹配，您可以中止该合并并继续在代码上工作一段时间，直到您准备好真正花费精力解决冲突。

肯定是正确的，你重新调整你的代码以便与trunk兼容（通过svn更新或合并更改），解决冲突就越容易。等到你准备好发现变化以发现一切都已经从你身下移动是非常可怕的 - 你将花费更多的时间来挖掘日志，试图找出变化是什么以及如何正确应用他们对你已经认为很好的代码，然后然后你需要用新的更改重新测试你的代码！如果你一直在合并，你已经测试了这个版本。

Answer 5

另一种方法是在你自己的分支中工作，而不是在主干中工作。这样，当您的功能/错误修复/无论何时完成时，唯一的合并就完成了。没有其他人会在你的分支上作出承诺，所以在你完成之前你是安全的。

Answer 6

• 每次坐在电脑前更新
• 每次提交前更新

=＆GT;多年无故障使用SCM。

Answer 7

• 根据需要随时更新。至少每天早上。并且，每次你的队友都会告诉你。每次你知道有人在你工作的地方犯了什么东西。

• 在你提交之前。在您更新到最新的存储库版本并且尽可能确保您的提交不会破坏任何内容之前，永远永远提交一些内容。

Answer 8

听起来很对。当然，如果你经常提交而不是等到你有大量的改变，那么这两种方法都是相同的。

Answer 9

我认为这完全取决于代码中的依赖项数量以及同时处理相同代码的开发人员数量。如果几乎没有开发人员使用相同的代码，那么您可以在不与存储库中的代码“合并”的情况下使用更长的时间。我个人喜欢等到我的开发结束，只要它不会花费我几个星期才完成。如果需要几周的时间才能完成，您应该将功能分成更小的部分，并使用更加增量的方法，这样您就可以检查新代码并更频繁地合并。

Answer 10

如上所述，我的建议很相似：

• 经常更新，尽可能多，但至少每天一次，
• 经常提交，同上（当然，您必须拥有已编译/正在运行/已测试的功能）

第二点也非常重要：一旦“某事”正在发挥作用，就必须承诺，文献中说“不要失明”，即不要保持在你的硬盘上开发一个月，直到完美（它永远不会是:-)）

这是Continuous Integration背后的基本思想（很多关于Martin Fowler网站的资料和非常明确的解释）。

太过分了：

• 关于“句法”冲突，不要担心它们，它们很少见，很容易修复，
• 关于“ semantic ”或“ architecture ”冲突，更快发现它们更为重要，因此上述座右铭：经常更新，经常提交，经常合并（对于使用DVCS的人），和经常测试集成函数，以发现那些潜在的语义冲突。

在我以前的工作中，产品部门的一些人会拒绝每天更新（甚至更少一天），因为他们说：“行李箱坏了，如果我更新，我会放松一天”。他们是对的！这是不可接受的！ 这就是为什么强调只应该提交（或推送给DVCS人员）非常重要的原因：帮助强制执行这个我设置的每日构建，这将在每次提交时开始（使用免费软件buildbot工具，但存在数十种类似的工具）。通过on-commit构建和测试，可以更容易地确定主干没有损坏;无论何时构建或（简单）测试失败，已经（刚）提交的人都会收到一封电子邮件，他们必须立即解决问题或恢复。并且网络摘要（在buildbot词汇表中称为瀑布）在这里供所有人查看。总而言之，在开发人员之间建立和相互信任真的是一种心态，但是一旦你达到这一点，相信我，你永远不会想要回来：开发更快但协调，人们我们很乐意为同一个代码做出贡献，而不是单独在他们的工作站上工作一个月！值得尝试走这条道路（恕我直言）。