然而,假设您有14个人在同一个产品上工作,这样会不会很快陷入14个并行分支的噩梦中?
例如,只有两个人,并且产品处于变更集X状态,现在两个开发人员在星期一早上开始独立的功能开发,因此两者都从相同的父变更集开始。
当他们提交时,我们现在有两个分支,然后使用14个人,我们将很快拥有需要合并回默认值的10+(可能不是14...)个分支。
或者...我看到了什么?也许这真的不是问题?
编辑:我看到有些人对我的问题存在一些困惑,所以让我澄清一下。
我非常清楚Mercurial很容易处理多个分支和合并,正如其中一个答案所述,即使人们在同一文件上工作,他们也不经常在同一行上工作,即使这样,冲突也很容易处理。我也知道,如果两个人因为在同一文件中更改了大量相同的代码而创建了合并地狱,那么这里存在一些整体规划失败,因为我们已经将两个功能放置在完全相同的位置上,给了两个开发者,而不是尝试让他们一起工作,或者一开始就把两个功能都交给一个开发者。
所以问题不在于此。
我想知道的是这些开源项目如何管理如此干净的历史记录。对我来说(正如一条评论所想),历史记录是否干净并不重要,我的意思是,我们确实在并行工作,仓库能够反映出这一点,那就更好了(在我看来),然而我查看的这些仓库却没有这种情况。它们似乎沿用Subversion模型,在这种模型下,您不能在更新和合并之前提交,这种情况下历史记录只是一条直线。
那么他们是如何做到的呢?
他们是否正在“变基”更改,使它们看起来像是遵循了分支最新提示,即使它们最初是在分支历史中提交的?移植changesets使它们看起来像是最初就在主分支中提交的?
或者我看过的项目要么太慢(目前,我没有深入了解历史),只有一个人在工作,实际上他们只添加了一些新功能?
或者他们将更改推送给一个中央维护者进行审查和集成?看起来并不是这样,因为我看过的许多项目在更改集上有不同的名称。