文件粒度与线粒度版本控制系统

Question

有哪些适用于文件和文件行的版本控制系统示例？

在我的理解中，一个在文件上工作的控制系统能够在没有文件冲突时自动管理合并：

例如：

A,B,C --> A',B',C
| (branch)  ___________ (merge) -> A',B',C'  
 -------> A,B,C'  

在哪些情况下，在线工作的版本控制系统能够自行管理合并，在哪些情况下它要求开发人员解决这些问题？

Answer 1

您的问题过于宽泛/笼统，但无论如何我都会尝试尝试一下。

现代版本控制系统中的大多数合并策略，无法处理以下问题：

假设您有文件 A B C 在提交 001 在存储库中。
开发人员Dev1 提交001 的分支并更改文件A 中的一行，提交为001a。
开发人员Dev2 提交001 的分支并更改文件A 中的同一行并提交为001b。

如果有人想合并提交001a 和001b，合并系统将无法判断哪个是该行的正确更改，也许项目的正确更改是使用提交中的内容001a 或者可能是提交中的001b，或者甚至可能是行中的两种更改的混合（必须有人创建）。

这通常是您遇到需要手动干预的冲突的原因，因为两个开发人员在同一个文件和行中工作并编写了不同的更改。

在其余情况下，结果是显而易见的：

• 两个提交都没有变化？合并结果没有变化。
• 任一提交的更改？更改将应用​​到合并中。
• 同一文件中的更改不同的行（例如，两个开发人员以不同的方法工作）？这两项更改都在合并中应用。