在集中版本控制中，经常进行更新是否总是一件好事？

假如说：

• 您的团队正在使用集中式版本控制。
• 您正在开发一个较大的功能，该功能可能需要几天才能完成，并且在此之前您将无法提交，因为这会破坏构建。
• 您的团队成员每天都会做一些事情，这些事情可能会更改您正在处理的某些文件。

由于这是集中的版本控制，因此您将必须在某个时候更新本地结帐：至少在提交新功能之前至少一次。

如果您在提交之前仅更新一次，那么由于您的队友进行的许多其他更改可能会导致很多冲突，这可能会一次解决所有冲突。

或者，您可以经常进行更新，即使每天有一些冲突需要解决，也应该一点一点地变得更容易。

您是否愿意经常更新始终是个好主意？

就个人而言，我每天都会更新本地版本。

在您描述的情况下，我会付出更多努力

• 为新的冗长功能创建一个分支。
• 通常从主线合并到这个新分支。

这条路，

• 您可以每天签入以将代码保留在服务器上
• 您不必担心通过签入破坏构建。
• 您可以使用存储库来撤消某些工作，或者在必要时使用较早的签入进行区分。
• 您一定要使用最新的代码库，并尽早检测到可能发生冲突的代码更改。

我看到的缺点是

• 与main的合并必须手动完成（或编写脚本）
• 需要更多的“管理”

是的，经常更新是个好主意。您经常进行更新，以避免困难的合并冲突，这是软件配置管理（SCM）知识的基础，并且存在发散性变化的问题。

不管它是集中式的还是分布式的；您与上游来源的分歧时间越长（意味着在DVCS情况下是中继，分支或其他存储库），合并冲突的机会就越大。是的，更新时可能会出现来自团队的令人讨厌的惊喜，但是推迟令人讨厌的惊喜会变得更糟（您等待的时间越长，人们对为什么进行一组更改的记忆就越少）。

要进行更新工作，这还意味着您和其他处理代码的程序员切勿故意提交或推送破坏构建的上游代码。这通常就是程序员分支（或从SCM术语上偏离上游）的原因，以防止您的团队成员和其他利益相关者在不可避免的情况下避免破坏代码。

您可以记住的口头禅是：“更新，更新，更新，提交”。在提交之前，请务必确保所做的更改与其他人一起使用。这也是为了确保首次签出代码也能正常工作。

问题中的第三个要点是完全错误的：

• 您正在开发一项新功能，该功能肯定需要几天的时间才能完成，并且在此之前您将无法提交，因为这会破坏构建。

如果您知道您将要处理一段时间内无法提交的内容，那就是使用分支的教科书示例。

不要将自己置于有大量待定更改的情况下。如果您知道一段时间后将无法提交到项目的主分支，请在另一个分支上工作。在那里，经常犯错。

如果你已经在这个问题所描述的情况，然后切换到一个分支，现在，提交您的更改，并继续在该分行工作。

通常，在CVCS中，经常更新是个好主意。但是，如果您在分支上工作，那么“经常更新或不更新”的问题就会变成“经常合并或不合并”。答案是肯定的。只需确保在从另一个分支合并之前，将所有待处理的更改（在分支中）提交即可，如果需要，可以选择安全地回滚合并。

我想你应该提交更多的时候。如果您要长时间工作几天，那么应该分支代码并在分支中工作，而不是直接在主干中工作。我知道在没有分支的情况下开始工作很方便，但是它并不是很灵活，因为您无法确定更新/提交是否会破坏您的代码，最终会导致您一直保持更新/提交直到做完你的工作。“功能分支”更好的方式是，您始终可以提交代码，并在完成后稍后再合并。

在分支策略中，更新已替换为从主干合并。根据我的经验，您不需要经常从主干中合并，因为五天时间跨度内的代码不会发生太大变化，并且仅在完成后才更容易解决冲突。

实际上，我发现在本地使用分布式版本控制更为方便。也就是说，我使用git作为Subversion客户端。这具有以下优点：

• 本地更改在更新之前已保存，因此，如果我在合并中出错，则可以随时返回并再次执行。
• 进行较大的更改时，我可以保存完成的零件。这样可以更轻松地检查正在进行的其余更改。
• 当我在较大的工作中修复错误时，我可以仅提交该修订，暂时提交其余修订，然后将“修复”“提交”到Subversion，同时将其他正在进行的工作保持在本地。

如果要添加新功能，是否可以创建新的单个源文件（以及匹配的外部接口头文件）？

我担心“新功能”具有广泛的影响吗？面向对象可能不再是曾经的流行语，但是这种范例有其优点。

这样，您可以创建框架（外部接口，以及存根函数）并承诺在完成其余开发工作的同时，应该将第三方影响降至最低。

在您描述的情况下，我认为拥有较小的源文件比拥有较少的较大文件更好。

集中版本控制与分布式版本控制有何不同？

在这两种情况下，您都必须在与开始内容相比其内容将被移动的地方签入。我看不到从中央存储库到您工作地点的合并频率的任何差异（而您的项目分支就是您的工作地点）。

我倾向于经常进行合并（至少每天一次，我也可能在其他方便的时候进行合并，或者当我知道有人检查了会影响我工作的内容时）。吸收较小的更改要容易得多，如果遇到问题，当您向他们询问刚签入的内容比一周前已经签入的内容时，人们会更有用。

顺便说一句，我不知道您所说的“破坏构建”。我倾向于以相对较小的增量进行工作，因此即使它破坏了某些功能，我也可以保持可编译状态。然后运行测试，以便使我知道合并并没有破坏某些应该起作用的东西。同样，较早发现问题更容易解决。

这取决于当别人破坏构建时您在“更新”方面的能力。一方面，您希望尽可能少地更新。就个人而言，几乎每当我发现有可用更新时，我都会进行更新。另一方面，如果构建中断，并且其他人需要一天的时间来修复它，那么您仍然希望能够同时使用新功能。

我使用的版本控制系统在更新完成后很难备份。在这些服务器上，我倾向于仅在需要检入之前进行更新。有了更好的版本控制系统，几乎没有理由不每天更新几次。