源代码管理-锁定与合并?[关闭]

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

• 大多数合并用户倾向于与他们正在开发的分支的“头”版本保持相当接近。这通常意味着戏剧性的合并问题并不常见。
• 在10年左右的合并模型使用中,我只经历了几个非常糟糕的合并问题。在这两个案例中,这是因为两个人解决了同一个问题。
• 我们通常在不与另一方通信的情况下解决合并问题;)
• 如果系统处于一个稳定的维护阶段,几乎没有变化,那么“锁定”vc模型是可以的。
• 如果你的团队很小(我想是1-2个人;),锁模型VC就可以了。

imho合并模型非常优越,因为它允许我在处理代码时自由。它可能不是一周内代码“变暗”的最佳模型,但对于“锁定”模型,这也是一个同样大的问题。一个星期内没人会因为密码而蒙在鼓里。

我很害怕自己合并的想法,在80年的记忆中尝试合并代码。然而,我下载了颠覆和Git,和他们玩了一点,并且对他们的承诺印象深刻。可惜我是这里唯一的一个。

我做了一件你可以尝试的事:跟踪你自己。由于锁定模型比较悲观,因此如果在该模型下工作,这很容易做到。每次你和另一个开发人员发生锁冲突时,都要过去和他们谈谈。跟踪以下内容:

1. 他们多少次不打算去检查/忘记它/不知道它被检查出来了。
2. 他们有多少次(度假、生病等)不可用。
3. 有多少次他们合法地检查它,但正在修改文件的完全不相关的部分到你想要修改的地方。
4. 多少次,他们修改了文件的一部分,这将与你想做的改变相冲突。

4是唯一可以证明锁对你有帮助的情况,包括 每一个 这样的事。在过去的三年里,我发现几乎所有的问题都是1-3个品种的问题。我想我找到过一个4。但是如果我把所有的时间加起来都是1-3,那就太棒了。

合并是正确的方法,但要在前面的答案基础上再加上一点,它应该尊重一些有效的标准。

• 分支定义得很好(它不代表“太广泛”的开发工作,开发人员将不得不修改 全部的 文件,将一个具有潜在冲突的公共文件的多次并发修改的机会相乘)
• 这个 通知 (当一个开发人员开始修改另一个同事已经保留的文件时,显然已经更改了文件)。
• 公共配置文件(每个开发人员都需要遵循一组预定义的值,但需要为每个程序员重新定义一个自定义本地路径除外)不是由任何人“保留”,而是在他们的私有工作区中简单地修改。

此外,请记住,也有可能两者兼而有之:

• “lock”:第一个修改文件的开发人员将是第一个提交文件的开发人员。每个其他开发人员也可以修改同一个文件,但在开始合并自己的修改之前,必须等待第一个提交。
• “合并”:当开发人员提交一个同事已经更改的文件时,他合并他的更改。

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

我认为合并模型是远远优越的,它更灵活,用户可以并行工作,从不等待彼此,并且解决冲突所花费的时间远小于锁定模型所丢失的时间。大多数情况下,对文件的更改不冲突,可以自动合并。

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

但最终,关键因素总是 用户通信 . 当用户沟通不畅时,冲突肯定会增加。

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

我遇到过的最大的合并问题是在一个我们有锁定版本控制(准确地说,是SCC)的站点上—这是一段时间以前的事了。

会发生的事情是,那个人A正在做一些事情,并将文件签出。人员B会收到一个紧急请求,要求为客户修复某些内容,并且必须更改该文件。

这有几种方式。有时,一个检查,B将作出改变,然后将继续从一个工作的副本,并消除了B的变化。有时,B会开始拷贝的副本,因为时间是至关重要的,改变可能需要一段时间才能正确,并覆盖一个变化。有时B的变化会与A的变化交互作用,而A的某些变化会被破坏或丢失。在后一种情况下没有警告。

在合并的VCS中,A和B进行更改,系统确保不会丢失任何内容。在最后一个案例中,风投注意到了冲突,所以不会错过。

对程序文件做更大的修改也是一个问题,因为它可能被必要的修复中断,使它更难完成。

我从未见过这样一个生产环境:可以保证两个人不必同时处理同一个文件。合并VCS可以很好地处理这种情况。没有锁定VCS。

合并很好。在同一文件上工作的程序员无论如何都应该进行通信。如果他们不通信,那代码中就有更严重的问题。

合并是一种自然的做事方式,它带来了纪律,节省了时间(想象一下两个程序员最终都重构了相同的代码)。

锁是被动的…合并是主动的…

如果有人主张这样做,那么锁定拥护者是错误的。我遇到的每一个使用老式锁定式系统的团队都对此表示不满,并渴望看到使用其他方法的人。我在一个地方做了一个项目,这个地方被迫使用一个锁定系统,并且选择完全不使用控制(所以我设置了一个 秘密 SVN分行,尽管我更喜欢BZR或Git)。

所以,我怀疑 锁定倡导者 “是锁定系统市场部的员工。

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

例如,使用Suffic,分支是指针复制,因此您可以轻松地创建一个尝试分支,以避免如果您正在尝试某些东西,但需要提交,则会损坏主干。

对于像git这样的分布式版本控制系统,每个签出实际上都是一个分支。

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

对锁定VCSE的常见抱怨是,当有人去度假或开会时,如果某些文件被锁定,您会遇到问题:)

我想这要看情况而定。 如果你知道控制飞机的文件被许多人同时改变,然后合并,你会乘坐飞机吗?

在愚蠢的应用程序中,可以使用合并方法,但如果我们讨论的是严肃的系统…比如银行系统等…