记录下 Linux 内核开发工作流程中，围绕 Git 展开的七个重要基本原则
每次 commit 只能做一件事
Linux 的中心原则是，所有更改都必须分解为小步骤进行 —— 您的每个 commit 都只能做一件事。这并不意味着每个 commit 都必须很小，比如对在数千个文件中使用的函数的 API 进行简单更改，可以使更改量很大，但仍然可以接受，因为它是针对某一项单一任务的更改。
通过始终遵循此原则，项目维护者可以更轻松地识别和隔离任何有问题的更改，而不影响其他的功能。
commit 不能破坏构建
不仅应该将所有更改分解为尽可能小的变量，而且还不能破坏内核。即每个步骤都必须完全起作用，并且不引起退化。这就是为什么对函数原型的更改还必须更新调用它的每个文件，以防止构建中断的原因。因此，每个步骤都必须作为一个独立的更改来工作
所有代码都是二等分的
如果在某个时候发现了错误，则需要知道是哪个更改导致了问题。从本质上讲，二等分是一种操作，它使开发者可以找到所有发生错误的确切时间点。
为此，请转到最后一个已知的工作 commit 所在的节点，并且已知第一个 commit 已损坏，然后在该点测试代码。如果可行，则前进到下一个节点；如果不是，则返回更上层的节点。
这样一来，开发者就可以在十几次编译/测试中，从成千上万的可能 commit 中分离出导致问题出现的 commit 。Git 甚至可以通过 git bisect 功能帮助自动化该过程。
重要的是，这只有在开发者遵守以前的规则的情况下才能很好地起作用：每个 commit 仅做一件事。否则，您将不知道是 commit 的许多更改中的哪一个导致了问题
如果 commit 破坏了构建让整个项目无法正常启动，同时等分线又恰好落在了该 commit 上，则您将不知道接下来是该往上一个节点测试还是往下一个节点测试，因为它们都有问题。
这意味着您永远都不应编写依赖于将来 commit 的 commit ，例如：调用尚不存在的函数，或更改全局函数的参数而不更改同一 commit 中的所有调用者。
永远不要 rebase 公共分支
Linux 项目工作流程不允许 rebase 他人使用的任何公共分支。因为 rebase 这些公共分支后，已重新基准化的 commit 将不再与基于原存储库中的相同 commit 匹配。在树的层次结构中，不是叶子的公共主干部分不能重新设置基准，否则将会破坏层次结构中的下游分支。
Git 正确合并
其他的版本管理系统是合并来自不同分支代码的噩梦，它们通常难以弄清代码冲突，并且需要大量的手动工作来解决。而 Git 的结构可以轻松完成这项工作，在 5.8-RC1 发布周期中，平均每天有 200 个 commit ，并从 5.7 版本中继承了 880 个合并。一些维护者注意到了其中增加的工作量，但是对此仍然没有感到什么太大的压力或者导致倦怠
保留定义明确的 commit 日志
每个 commit 都必须是独立的，这也应该包括与该 commit 相应的日志。更改的代码越少，日志反而应该说明得更详细。
在一个 commit 过了几年之后，几乎没有人会记得当初为什么进行更改。Git 的 blame 功能就可以显示这些代码的修改记录。
持续测试和集成
最后一项基本原则是开发过程中进行持续测试和持续集成。在向上游发送 commit 请求之前，开发者会测试每个 commit 。Linux 社区还有一个名为 Linux-next 的镜像 ，它提取维护人员在其存储库的特定分支上进行的所有更改，并对其进行测试以确保它们能正确集成。
Linux-next 非常有效地运行着整个内核的可测试分支，该分支将用于下一个发行版。Linux-next 是一个公共仓库，任何人都可以测试它，这种情况经常发生 —— 人们现在甚至发布有关 Linux-next 中代码的错误报告。事实上，已经进入 Linux-next 几周的代码基本上可以确定会最终进入主线发行版中。
社区文化
Linux 内核社区内部存在一种持续改进的文化，这使他们能够首先采用这些实践。
同时他们还有一种信任的文化，“我们有一条清晰的途径，人们可以通过该途径做出贡献，并随着时间的推移证明他们愿意且有能力推进该项目的发展。这将建立一个相互信任的关系网，这些关系对于项目的长期成功至关重要。”
所有的这些原则制度及社区文化支持着 Linux 社区在每个版本迭代平均 10,000 次 commit (最后一个版本超过 14,000 次 commit) ，发布令人难以置信的可靠代码，促使 Linux 内核开发工作流程被视为软件开发行业黄金标准
