linux - 分支与 merge 策略 - Linux 内核

Question

背景

从上个月的 Linux GitHub 页面来看，超过 500 位作者已将 1946 项提交推送到所有分支(不包括 merge )。

在 master 上，11,000 多个文件已更改，其中添加了 549K 个文件，删除了 308K 个文件。

1 个月内 600 名开发者接触了 800K loc。

所有开发人员分布在全局并独立工作。他们不是由单一经理管理的。

Linux 内核仍然可以工作!!!

<小时/>

工作流程

以下是我遇到的两个工作流程:

待定:

[![在此处输入图像描述][1]][1][1]:/image/5yVy4.png

Gitflow 工作流程:

[![在此处输入图像描述][2]][2][2]:/image/KRcIZ.png

<小时/>

1. Linux 内核开发人员遵循什么工作流程？基于工作流程， merge 策略是什么？保持 master 分支代码不发生冲突。

2. 在从本地存储库(笔记本电脑)进行 git Push 更改之前，您是否使用某些基线预先验证提交？验证VCS或非 VCS 冲突

3. 在什么情况下，Linux 内核开发人员会对提交进行标记/标记？

Answer 1

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

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