commit 不能破坏构建
不仅应该将所有更改分解为尽可能小的变量，而且还不能破坏内核。即每个步骤都必须完全起作用，并且不引起退化。这就是为什么对函数原型的更改还必须更新调用它的每个文件，以防止构建中断的原因。因此，每个步骤都必须作为一个独立的更改来工作，这将我们带到了下一点：
所有代码都是二等分的
如果在某个时候发现了错误，则需要知道是哪个更改导致了问题。从本质上讲，二等分是一种操作，它使开发者可以找到所有发生错误的确切时间点。
为此，请转到最后一个已知的工作 commit 所在的节点，并且已知第一个 commit 已损坏，然后在该点测试代码。如果可行，则前进到下一个节点；如果不是，则返回更上层的节点。这样一来，开发者就可以在十几次编译/测试中，从成千上万的可能 commit 中分离出导致问题出现的 commit 。Git 甚至可以通过 git bisect 功能帮助自动化该过程。
重要的是，这只有在开发者遵守以前的规则的情况下才能很好地起作用：每个 commit 仅做一件事。否则，您将不知道是 commit 的许多更改中的哪一个导致了问题；如果 commit 破坏了构建让整个项目无法正常启动，同时等分线又恰好落在了该 commit 上，则您将不知道接下来是该往上一个节点测试还是往下一个节点测试，因为它们都有问题。这意味着您永远都不应编写依赖于将来 commit 的 commit ，例如：调用尚不存在的函数，或更改全局函数的参数而不更改同一 commit 中的所有调用者。
永远不要 rebase 公共分支
Linux 项目工作流程不允许 rebase 他人使用的任何公共分支。因为 rebase 这些公共分支后，已重新基准化的 commit 将不再与基于原存储库中的相同 commit 匹配。在树的层次结构中，不是叶子的公共主干部分不能重新设置基准，否则将会破坏层次结构中的下游分支。