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