我希望这听起来不太一般;我会尝试尽可能具体。
我正在学习如何使用Git，而我无法绕过合并并行处理的分支（我可以理解线性工作流和线性场景中版本控制的价值，包括有多个分支进行比较，其中只有一个将存活而其他人将被丢弃）。
但我看不出并行分支如何保证没有冲突（Atlassian guide称之为“集成代码和共享更改的故障安全机制”）。我认为在一个大型项目中，很有可能一次改变，它本身就能发挥作用，打破另一种改变，这种改变也可以独立发挥作用，但我读过的指南（以及后来的视频我都是）已经诉诸于）似乎只是绕过这一点。
This guy on Youtube声称唯一可能的问题是当人们编辑相同的代码行时（在这种情况下Git会要求你修复冲突），但这根本不是真的（我设法创建一个简单的反例例子在分支时工作的不同地方的编辑在合并时使代码错误，并且Git报告没有冲突和成功合并）。
当然，你可以测试合并的代码并且（可能）捕获bug，但即便如此，这也意味着有人会挖掘不同分支的代码来解开它（从而击败了单独的功能开发所声称的好处）。
我想它必须以某种方式工作（否则，Linux和其他大型项目是不可能的），但我只是无法找到有关如何的信息。
你做了一些不好的假设。此外，要么您从不良来源获取信息，要么这些错误的假设会导致您误解您所获得的信息。
合并并不能保证没有错误，没有人知道他们在说什么会说它是。然而，实际上很少在大型但设计良好的系统中两个补丁相互破坏，除非存在直接的代码冲突。
您绝对应该测试每个版本，包括合并结果。这是我不喜欢随意历史重写的原因之一（例如，依赖于强迫性变基的工作流程以保持历史完全线性）：因为实际上没有人测试由这些工作流程产生的所有自动生成的版本。这也是为什么需要可靠的单元测试来覆盖系统定义的行为。 （人们错误地认为测试需要“覆盖代码”;这是无稽之谈。他们需要满足要求。）良好的单元测试是快速和自动化的，所以无论如何你都要运行它们。
是的，在罕见的情况下，合并引入了一个错误，你必须追捕它。就像手动引入错误而不立即注意到的那样，你必须将它追捕。
在git中有支持进行搜索（例如bisect命令），只要你通常确保你保留的每个提交都是一个“干净”的版本（构建并传递定义的测试套件），这是很有用的。但即便如此，如果你知道合并的直接父母都是自己工作的，那么你通常应该能够检查合并提交和它的父母之间的差异并找到那里的bug，甚至不需要挖掘进入历史。