Git/Linux：使用来自多个 Git 存储库的补丁来维护 Linux 内核的好策略是什么？答案

【问题标题】：Git/Linux: What is a good strategy for maintaining a Linux kernel with patches from multiple Git repositories?Git/Linux：使用来自多个 Git 存储库的补丁来维护 Linux 内核的好策略是什么？
【发布时间】：2011-03-28 17:49:19
【问题描述】：

我正在维护一个自定义 Linux 内核，该内核由来自各种来源的合并更改组成。这是针对嵌入式系统的。

与我们合作的芯片供应商发布了一个板级支持包，作为对主线内核 (2.6.31) 的更改。此后，我进行了更改以支持我们的自定义硬件，并与稳定的 (2.6.31.y) 内核版本合并。我还合并了我们使用的特定文件系统驱动程序的错误修复，有时在更改进入主线内核之前。

对于如何管理各种贡献来源和我自己的更改，我并不是很系统。如果变化很大，我倾向于合并；如果它很小，我倾向于将第三方变更集重新定位到我自己的基础上。一般来说，合并冲突很少见，因为我的大部分工作都会影响到不在主线内核中的驱动程序。

我想知道是否有更好的方法来管理所有这些。一个问题是我的更改与合并混合在一起。历史可能类似于：

2.6.31 + 板级支持包 + 我的更改 (1) + 2.6.31.12 更改 + 我的更改 (2) + 文件系统驱动程序更新 + 我的更改 (3) + 2.6.31.14 更改 + 我的更改 (4) + ....

我有点担心我的更改混入其中，有时是在合并的另一端。有一个更好的方法吗？特别是，当我切换到较新的内核时，有没有一种方法可以让生活更轻松？

【问题讨论】：

标签： linux git

【解决方案1】：

我认为清理您当前的设置并不容易，除非您的历史相当短，但我建议这样做：

设置一个主存储库，该存储库为您的代码来自的每个其他位置设置远程 - 主线内核、补丁......

为您的驱动程序供应商的更新保留一个单独的分支。

当你获取时，更新不会弄乱你的分支。

当你准备好合并时，合并到某种“发布”分支。这个想法是让每个源与其他源分开，除非需要合并。将您的更改基于此分支，并根据需要进行合并/变基。

这是一个快速图表，希望对您有所帮助：

mainline-\----------\-------------------------------\
          \           \              /you---\---/-/  \
           \release----\-/---/----/-/--------\-/ /  --\-----
patches-----------------/---/    /              /
                                /              /
driver-------------------------/--------------/

有这么多分支，很难有效地绘制图表，但我希望这能让你明白我的意思。 release 保存您系统的官方代码，you 保存您自己的修改，driver 保存来自驱动程序供应商的补丁，patches 保存来自其他 repo 的补丁，mainline 是主线内核。一切都被合并到release，您的更改基于release，但只能通过在每个方向上合并进行交互，而不是直接对release进行更改。

【讨论】：

【解决方案2】：

我认为普遍接受的最佳策略是 (a) 补丁集 (b) 主题分支

主题分支本质上是相同的，但会定期重新定位到主线。 Topgit 是一个众所周知的工具，如果你有很多主题分支，它可以让处理主题分支“更容易”。否则：提前计划并限制分支机构的数量

【讨论】：