源控制 - 锁定与合并？

Question

许多使用Visual Studio的程序员很难适应这样一个事实，即在其他源代码控制系统中，文件不需要在任何给定时间锁定/签出给一个开发人员。

合并的支持者说，允许两个人在同一个文件上工作可以提高工作效率，因为它可以消除对同一源文件的排队。它还避免了需要编写代码的情况，但是对于刚刚离开两周假期的人来说，这个源代码已被检出。

锁定拥护者说，当多个人同时在同一个文件上工作时会引入很多风险。根据他们的说法，在使用合并模型时，团队成员之间的沟通和协调变得更加必要。此外，很多人似乎不信任自动合并。

使用一种方法而不是另一种方法的最有说服力的理由是什么？

Answer 1

从锁定模型切换到合并模型后，我将进行以下观察：

• 大多数合并用户往往非常接近他们正在开发的分支机构的“头部”版本。这通常意味着戏剧性的合并问题并不常见。
• 在10年左右的合并模型使用中，我只遇到了几个非常糟糕的合并问题。在这两种情况下，这都是因为有两个人解决了同样的问题。
• 我们通常在不与对方通信的情况下解决合并问题;）
• “锁定”模式VC如果系统处于稳定维护阶段且几乎没有变化，则表示正常。
• 如果您的团队很小（我会说1-2人;）
，锁定模型VC是可以的

恕我直言合并模型非常优越，因为它允许我在使用代码时自由。它可能不是使用1周的代码“变暗”的最佳模型，但是再次使用“锁定”模型这是一个同样大的问题。一个星期以来代码没有人会变黑。

Answer 2

我非常害怕合并自己的想法，有关于在80年代尝试合并代码的nighmares的记忆。但是，我下载了Subversion和Git并与他们玩了一下，并对他们的承诺印象深刻。很遗憾，我是这里唯一的人。

我做过的一件事你可以尝试：跟踪自己。由于锁定模型更加悲观，如果您在该模型下工作，这很容易做到。每次与其他开发人员发生锁定冲突时，请与他们交谈。跟踪以下内容：

1. 他们多少次没有意思去检查/忘记它/不知道它已被检查出来。
2. 他们没有多少次（度假，生病等）。
3. 他们合法地检查了多少次，但是将文件中完全不相关的部分修改为您想要修改的部分。
4. 他们修改了与您想要进行的更改冲突的部分文件的次数。

4是唯一可以证明锁定对你有帮助的情况，并且涵盖每个这样的事件。在过去的3年里，我发现我一直在做的事情是，几乎每个问题都是1-3种。我想我发现了一次。但是，如果我把所有丢失的时间加起来为1-3，那就太棒了。

Answer 3

合并是正确的方法，但要添加到上一个答案，它应该尊重一些标准才能有效。

• 分支定义明确（它不代表“过于宽泛”的开发工作，开发人员必须修改所有文件，将机会与一个公共文件的多个并发修改相乘潜在的冲突）
当一位开发人员开始修改另一位同事已经保留的文件时，
• 通知（文件已被更改）显然已经完成。
• 常见配置文件（每个开发人员需要遵循一组预定义值，除了需要为每个程序员重新定义的一个自定义本地路径之外）不是任何人“保留”的，而只是在他们的私人工作空间。

另外，请记住，还可以将两者结合使用：

• “lock”：第一个修改文件的开发人员将是第一个提交它的人。其他所有开发人员也可以修改同一个文件，但在开始合并自己的修改之前必须等待第一个文件提交。
• “merge”：当开发人员提交已由同事更改的文件时，他会合并他的更改。

在这种情况下，您应该确保存在“释放”机制，以避免被第一个开发人员阻止。

Answer 4

我认为合并模型更优越，更灵活，用户可以并行工作，永不等待，解决冲突所需的时间远远少于锁定模型所损失的时间。大多数情况下，对文件所做的更改不会发生冲突，并且可以自动合并。

这可能就是为什么它是大多数现代源控制系统中的默认模型。

但最终，关键因素始终是用户沟通。当用户沟通不畅时，肯定会发生冲突。

Answer 5

合并模型有点像游泳。一开始没有做过的人都害怕它，但是每个知道怎么做的人都喜欢它。有些人在早期就有不好的经历，大多数人只需要体验它并克服最初的恐惧。

Answer 6

我遇到过的最大的合并问题是在我们有锁定版本控制的网站上（SCCS，确切地说 - 这是前一段时间）。

会发生什么事情，那个人A会做某事，并且会检查该文件。 B人会收到一个紧急请求，要求为客户修理一些东西，并且必须更改该文件。

这在几个方面发挥了作用。有时，A会检查，B会做出改变，然后A会继续从A的工作副本中消除B的变化。有时，B会开始使用复制的副本，因为时间非常重要，而且更改可能需要一段时间才能完成，并且会覆盖A的更改。有时B的变化会与A的变化相互作用，而A的一些变化会被破坏或丢失。在后一种情况下没有任何警告。

在合并VCS中，A和B进行更改，系统确保不会丢失任何内容。在最后一种情况下，VCS注意到冲突，因此不会错过。

对程序文件进行更大的更改也存在问题，因为它可能会被必要的修复程序中断，从而使其更难完成。

我从未见过一个生产环境，可以保证两个人几乎不会同时在同一个文件上工作。合并VCS可以很好地处理这种情况。锁定VCS不会。

Answer 7

合并很好。无论如何，处理同一文件的程序员应该进行通信。如果他们没有进行通信，则该代码中存在严重问题。

合并是一种自然的做事方式，它带来纪律，节省时间（想象一下程序员最终重构相同的代码）。

锁定是被动的...合并是主动的......

Answer 8

锁定倡导者是错误的，如果有人提倡这样做的话。我使用老式锁定风格系统遇到的每个团队都抱怨过，并且长时间地看着使用其他方法的人。我在一个地方工作，被迫使用一个锁定系统，并选择使用NO CONTROL（所以我设置了一个秘密 SVN分支，即使我更喜欢Bzr或Git）

所以，我怀疑唯一的“锁定拥护者”是锁定系统营销部门的员工。

Answer 9

锁定文件可能无法很好地扩展到更大的团队。对于使用大量分支和合并的版本控制系统，让任何一个人对存储库进行这样的控制可能是不切实际的（因此，不能扩展到更大的团队）。

例如，使用Subversion，分支是指针副本，因此如果您正在尝试某些东西但想要提交，则可以轻松创建TRY分支以避免损坏主干。

对于像Git这样的分布式版本控制系统，每次检查都是一个分支。

Answer 10

合并总是有问题且适得其反，应不惜一切代价避免。合并大型代码更改和重构文件是一件痛苦的事。强制所有开发人员使用乐观锁定模型是错误的。

Answer 11

针对锁定VCS的常见抱怨是，当某人去度假或会议时，如果某些文件被锁定，则会出现问题：）

Answer 12

我认为这取决于具体情况。 如果您知道控制飞机的文件被许多人同时更改然后合并，您会乘坐飞机吗？

在愚蠢的应用程序中可以使用合并方法，但如果我们谈论的是严肃的系统......就像银行系统一样......