分支与合并策略-Linux内核

Question

背景

上个月在Linux GitHub页面上，超过500位作者将1946年的提交推向了所有分支机构，不包括合并。

master上的11,000+个文件已更改，添加了54.9万个文件，删除了30.8万个文件。

600个开发人员在1个月内触摸了80万个位置。

所有开发人员都在全球分布并独立工作。他们不是由一个经理来管理。

Linux内核仍然有效！

---

工作流程

下面是我遇到的两个工作流程：

待定：

Gitflow工作流程：

1）Linux内核开发人员应遵循的工作流程是什么？根据工作流，合并策略是什么？保持master分支代码没有冲突。

2）在git push从本地存储库（笔记本电脑）进行更改之前，您是否使用一些基准对提交进行了预验证？验证VCS或非VCS冲突

3）在什么情况下，Linux内核开发人员是否标记/标记提交？

Answer 1

ProGit的第123页告诉我，Linux内核使用“独裁者和中尉的工作流程”（Section Distributed Workflows in ProGit）

通过这种方式，提交的验证被分为不同的阶段，每个blob都会被我多次审查。由于我自己不是Linux Kernel开发人员，因此我不知道如何标记提交的准则。