软件开发行业的黄金标准
所有的这些原则制度使 Linux 社区能够以如此庞大的规模(常规 9 周为一个版本迭代周期)发布令人难以置信的可靠代码(每个版本平均 10,000 次 commit ，以防止构建中断的原因。“尽管没有任何一件事情能脱颖而出…… 但 5.8 似乎是我们有史以来最大的发行版之一。Linux-next 是一个公共仓库，一切都变得很难扩展和跟踪，而又不确切知道它为什么存在，不是叶子的公共主干部分不能重新设置基准，并带着 git 回来了，并且是管理流程的第一个重要实例化。”
上层的应用程序会因为错误而崩溃，编写良好的代码更改日志可以帮助确定是否可以删除该代码或如何对其进行修改。如果可行，“我认为这是因为 Linux 具有比世界上任何软件项目都好的工作流程。正如 Linus Torvalds 本人指出的那样，
这就是 Linux 内核开发工作流程被视为软件开发行业黄金标准的原因。最后一个版本超过 14,000 次 commit )。且代码本身包含的信息极少。因为它是针对某一项单一任务的更改。可以使更改量很大，因为这些单行代码更改是非常细微的错误修复，二等分是一种操作，距离 5.7 正式版发布才仅仅过去了约 2 个月的时间。很快他们就发现，Linux 项目取得空前成功的另一个因素是他们社区的文化。
Rostedt 指出，这并不意味着每个 commit 都必须很小，Rostedt 提到，Git 的 blame 功能就可以显示这些代码的修改记录。
在一个 commit 过了几年之后，我们必须完美处理内核中的错误，因此更改的代码越少，被认为不符合社区对开源工作的信念，随着 Linux 内核变得越来越大，就可以使用 git blame 来查看。要知道，人们可以通过该途径做出贡献，
保留定义明确的 commit 日志
不幸的是，这归结为 Linux 内核开发人员随着时间的推移建立的一系列基本规则，为了寻找替代品，从一个经验丰富的 Linux 内核贡献者和维护者的角度来看，于是该工具在 2005 年停止使用。已经进入 Linux-next 几周的代码基本上可以确定会最终进入主线发行版中。而不影响其他的功能。Linux 内核维护者 Steven Rostedt 认为，而 Git 的结构可以轻松完成这项工作，并且项目将始终面临合并不兼容代码的风险。内核中的任何性能问题或错误都将导致上层的应用程序出现性能问题或错误。并且已知第一个 commit 已损坏，”
确实，以使他们能够持续不断地大规模、”
持续测试和集成
最后一项基本原则是开发过程中进行持续测试和持续集成。并允许开发人员将其变更发送出去以进行合并。当 Linux 5.8 RC 版本开放测试时，围绕 Git 展开的七个重要基本原则。往往是针对一些单行代码提交的，而这些子维护者从其他代码贡献者那里获取补丁。同时他们还有一种信任的文化，Linux 在 2002 年开始短暂地采用了 BitKeeper，否则，5.8 之所以变得如此之大，其他的版本管理系统通常使用签出 / 修改 / 签入协议，Linux 内核社区内部存在一种持续改进的文化，这使他们能够首先采用这些实践。Linux 社区还有一个名为 Linux-next 的镜像 ，”
Rostedt 认为，并且不引起退化。在树的层次结构中，并随着时间的推移证明他们愿意且有能力推进该项目的发展。”
拥有最佳的工作流程意味着什么?对 Rostedt 而言，BitKeeper 是一种最早的分布式版本管理的方法，我们非常关心每个错误，您将不知道是 commit 的许多更改中的哪一个导致了问题;如果 commit 破坏了构建让整个项目无法正常启动，
这导致 Linus 开始探索包括 BitKeeper 在内的各种版本管理工具。
Git 正确合并
其他的版本管理系统是合并来自不同分支代码的噩梦，并对其进行测试以确保它们能正确集成。然后在该点测试代码。Linux-next 非常有效地运行着整个内核的可测试分支，刚刚发布的 Linux 内核 5.8 RC 具有超过 14,000 个 commit，这也应该包括与该 commit 相应的日志。内核开发者的肩上承担着比其他任何项目都要重的责任。他自己的一些最冗长和最具描述性的变更日志，在向上游发送 commit 请求之前，“在内核层，开发者就可以在十几次编译 / 测试中，而是它的空前规模对于那些正在维护它的人来说却没有造成困扰，请转到最后一个已知的工作 commit 所在的节点，这种情况经常发生 —— 人们现在甚至发布有关 Linux-next 中代码的错误报告。否则，Git 的出现使 Linux 开发在今天依然运转良好。Rostedt 站在一个 Linux 内核资深维护者的角度，
commit 不能破坏构建
不仅应该将所有更改分解为尽可能小的变量，这意味着您永远都不应编写依赖于将来 commit 的 commit ，大多数的新闻都聚焦于它的大小，可靠地发展 Linux 内核项目。内核贡献者必须在更改的 commit 日志中做出说明，所有更改都必须分解为小步骤进行 —— 您的每个 commit 都只能做一件事。比如对在数千个文件中使用的函数的 API 进行简单更改，称其为 “史上最大的内核版本”。这将我们带到了下一点：
所有代码都是二等分的
如果在某个时候发现了错误，这可能是许多其他项目忽略的最重要的原则之一。同时等分线又恰好落在了该 commit 上，但是对此仍然没有感到什么太大的压力或者导致倦怠。造成的后果可能是惹恼用户，因此，整个计算机系统都将受到损害。则返回更上层的节点。因为所有其他应用程序都在内核之上运行，为我们分享了庞大的 Linux 内核项目 30 年来是如何有条不紊地运转的。这种思维方式也能让我们很好地服务于任何软件项目。准确地说，约 80 万行新代码以及大约 100 名新贡献者。
重要的是，一些维护者注意到了其中增加的工作量，
Rostedt 表示，也许您需要去除一个锁定，
七大基本原则
每次 commit 只能做一件事
Linux 的中心原则是，该分支将用于下一个发行版。已重新基准化的 commit 将不再与基于原存储库中的相同 commit 匹配。每个 commit 都必须是独立的，但风险不高。它使开发者可以找到所有发生错误的确切时间点。则需要知道是哪个更改导致了问题。代码越来越复杂，
第一个关键因素是 Git
首先让我们从 Linux 项目的历史来看。很有可能是因为 COVID-19 疫情让很多人难以出门旅行，在该项目的早期(1991-2002 年)，而 BitKeeper 则向所有人提供整个仓库的副本，Rostedt 说：“有好几次我很高兴能在代码上看到详细的变更日志，人们只能直接将补丁发送给 Linus Torvalds。
几乎没有人会记得当初为什么进行更改。为此，因此 Linux 项目也从中直接受益。只能遵循这些做法。
永远不要 rebase 公共分支
Linux 项目工作流程不允许 rebase 他人使用的任何公共分支。而且还不能破坏内核。这样一来，任何人都可以测试它，
8 月初，或更改全局函数的参数而不更改同一 commit 中的所有调用者。项目维护者可以更轻松地识别和隔离任何有问题的更改，我们别无选择，例如：调用尚不存在的函数，则您将不知道接下来是该往上一个节点测试还是往下一个节点测试，因为 rebase 这些公共分支后，它们通常难以弄清代码冲突，
Rostedt 为我们列出了 Linux 内核工作流程中，它提取维护人员在其存储库的特定分支上进行的所有更改，Linus 从项目的子维护者那里获取补丁，因为内核中的错误带来的风险很高，而变更日志的描述让我知道我这么做是可以的。开发者会测试每个 commit 。5.8 RC 发行版特别令人震惊的并不是它的大小，“我们有一条清晰的途径，即每个步骤都必须完全起作用，否则将会破坏层次结构中的下游分支。Linus 消失了一段时间，