源控制 - 锁定与合并？

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

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

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

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