Git 正确合并
其他的版本管理系统是合并来自不同分支代码的噩梦，它们通常难以弄清代码冲突，并且需要大量的手动工作来解决。而 Git 的结构可以轻松完成这项工作，因此 Linux 项目也从中直接受益。这就是为什么 5.8 版本的大小并不重要的重要原因。在 5.8-RC1 发布周期中，平均每天有 200个 commit ，并从 5.7 版本中继承了 880 个合并。一些维护者注意到了其中增加的工作量，但是对此仍然没有感到什么太大的压力或者导致倦怠。
保留定义明确的 commit 日志
不幸的是，这可能是许多其他项目忽略的最重要的原则之一。每个 commit 都必须是独立的，这也应该包括与该 commit 相应的日志。内核贡献者必须在更改的 commit 日志中做出说明，让所有人了解与正在进行的更改相关的所有内容。Rostedt 提到，他自己的一些最冗长和最具描述性的变更日志，往往是针对一些单行代码提交的，因为这些单行代码更改是非常细微的错误修复，且代码本身包含的信息极少。因此更改的代码越少，日志反而应该说明得更详细。
在一个 commit 过了几年之后，几乎没有人会记得当初为什么进行更改。Git 的 blame 功能就可以显示这些代码的修改记录。比如一些 commit 可能非常古老，也许您需要去除一个锁定，或者对某些代码进行更改，而又不确切知道它为什么存在，就可以使用 git blame 来查看。编写良好的代码更改日志可以帮助确定是否可以删除该代码或如何对其进行修改。Rostedt 说：“有好几次我很高兴能在代码上看到详细的变更日志，因为我不得不删除这些代码，而变更日志的描述让我知道我这么做是可以的。”
持续测试和集成
最后一项基本原则是开发过程中进行持续测试和持续集成。在向上游发送 commit 请求之前，开发者会测试每个 commit 。Linux 社区还有一个名为 Linux-next 的镜像 ，它提取维护人员在其存储库的特定分支上进行的所有更改，并对其进行测试以确保它们能正确集成。Linux-next 非常有效地运行着整个内核的可测试分支，该分支将用于下一个发行版。Linux-next 是一个公共仓库，任何人都可以测试它，这种情况经常发生 —— 人们现在甚至发布有关 Linux-next 中代码的错误报告。事实上，已经进入 Linux-next 几周的代码基本上可以确定会最终进入主线发行版中。
