Git合并并行分支如何避免引入bug？
How does merging parallel branches in Git avoid introducing bugs?
我希望这听起来不太笼统；我会尽量具体。
我正在学习如何使用 Git，但我无法集中精力合并正在并行处理的分支（我可以理解线性工作流和版本控制的价值线性场景，包括有多个分支进行比较，其中只有一个会存活而其他的将被丢弃）。
但我看不出并行分支如何保证没有冲突（Atlassian guide 称之为"a fail-safe mechanism for integrating code and sharing changes"）。我认为在一个大型项目中，一个单独工作的更改很可能会破坏另一个也单独工作的更改，但是我读过的指南（以及后来我的视频） ve resorted to) 似乎只是在绕过这一点。
This guy on Youtube 声称唯一可能的问题是当人们编辑相同的代码行时（在这种情况下 Git 将要求您修复冲突），但这根本不是真的（我设法创建了一个简单的反例，其中在分支时工作的不同位置的编辑在合并时使代码错误，并且 Git 报告没有冲突并且合并成功）。
当然，您可以测试合并后的代码并（也许）捕获错误，但即便如此，这也意味着有人会深入研究不同分支的代码来解决它（从而破坏单独功能开发所声称的好处） .
我想它 必须 以某种方式工作（否则，Linux 和其他大型项目将不可能实现），但我一直无法做到查找有关 如何.
的信息
您做出了一些错误的假设。此外，要么是您从错误的来源获取信息，要么是那些错误的假设导致您误解了所获取的信息。
合并不能保证没有错误，而且知道他们在谈论什么的人不会说它是。 但是，在实践中很少有两个补丁在一个大的 but well-designed 系统中相互破坏，除非有直接代码冲突。
您绝对应该测试每个版本，包括合并结果。这是我不喜欢随意重写历史记录的原因之一（例如，依赖强迫性变基来保持历史记录完全线性的工作流）：因为实际上没有人测试这些工作流产生的所有 auto-generated 版本。这也是您需要覆盖系统定义行为的可靠单元测试的原因。 （人们错误地认为测试需要 "cover the code"；那是无稽之谈。它们需要满足需求。）好的单元测试是快速且自动化的，因此无论如何您在每次构建时都会 运行 它们。
是的，在合并引入错误的极少数情况下，您必须找到它。就像当一个 bug 被人为引入但没有立即被发现时，你必须找到它。
git 中支持进行搜索（例如 bisect 命令），只要您通常确保保留的每个提交都是 "clean" 版本（构建并通过定义的测试套件）。但即便如此，如果您知道合并的两个直接父项都是独立工作的，那么您通常应该能够检查合并提交与其父项之一之间的差异并找到那里的错误，甚至不需要挖掘载入史册。
我希望这听起来不太笼统；我会尽量具体。
我正在学习如何使用 Git，但我无法集中精力合并正在并行处理的分支（我可以理解线性工作流和版本控制的价值线性场景，包括有多个分支进行比较，其中只有一个会存活而其他的将被丢弃）。
但我看不出并行分支如何保证没有冲突（Atlassian guide 称之为"a fail-safe mechanism for integrating code and sharing changes"）。我认为在一个大型项目中，一个单独工作的更改很可能会破坏另一个也单独工作的更改，但是我读过的指南（以及后来我的视频） ve resorted to) 似乎只是在绕过这一点。
This guy on Youtube 声称唯一可能的问题是当人们编辑相同的代码行时（在这种情况下 Git 将要求您修复冲突），但这根本不是真的（我设法创建了一个简单的反例，其中在分支时工作的不同位置的编辑在合并时使代码错误，并且 Git 报告没有冲突并且合并成功）。
当然，您可以测试合并后的代码并（也许）捕获错误，但即便如此，这也意味着有人会深入研究不同分支的代码来解决它（从而破坏单独功能开发所声称的好处） .
我想它 必须 以某种方式工作（否则，Linux 和其他大型项目将不可能实现），但我一直无法做到查找有关 如何.
的信息您做出了一些错误的假设。此外，要么是您从错误的来源获取信息，要么是那些错误的假设导致您误解了所获取的信息。
合并不能保证没有错误，而且知道他们在谈论什么的人不会说它是。 但是，在实践中很少有两个补丁在一个大的 but well-designed 系统中相互破坏，除非有直接代码冲突。
您绝对应该测试每个版本，包括合并结果。这是我不喜欢随意重写历史记录的原因之一（例如，依赖强迫性变基来保持历史记录完全线性的工作流）：因为实际上没有人测试这些工作流产生的所有 auto-generated 版本。这也是您需要覆盖系统定义行为的可靠单元测试的原因。 （人们错误地认为测试需要 "cover the code"；那是无稽之谈。它们需要满足需求。）好的单元测试是快速且自动化的，因此无论如何您在每次构建时都会 运行 它们。
是的，在合并引入错误的极少数情况下，您必须找到它。就像当一个 bug 被人为引入但没有立即被发现时，你必须找到它。
git 中支持进行搜索（例如 bisect 命令），只要您通常确保保留的每个提交都是 "clean" 版本（构建并通过定义的测试套件）。但即便如此，如果您知道合并的两个直接父项都是独立工作的，那么您通常应该能够检查合并提交与其父项之一之间的差异并找到那里的错误，甚至不需要挖掘载入史册。