我正在维护一个自定义Linux内核，它包含来自各种来源的合并更改。这适用于嵌入式系统。
我们正在使用的芯片供应商发布了一个板级支持包作为对主线内核的更改（2.6.31）。我已经进行了更改以支持我们的自定义硬件，并且还与稳定的（2.6.31.y）内核版本合并。我还合并了我们使用的特定文件系统驱动程序的错误修复，有时在更改进入主线内核之前。
我对如何管理各种贡献来源和我自己的变化并不是很系统。如果变化很大，我倾向于合并;如果它很小，我倾向于将第三方变更设置为我自己。一般来说，合并冲突很少见，因为我的大部分工作都会影响主线内核中不存在的驱动程序。
我想知道是否有更好的方法来管理所有这些。一个问题是我的变化与合并混合在一起。历史可能看起来像：
2.6.31 +主板支持包+我的更改（1）+ 2.6.31.12更改+我的更改（2）+文件系统驱动程序更新+我的更改（3）+ 2.6.31.14更改+我的更改（4）+ ....
我担心我的变化有点混乱，有时候在合并的另一边。有一个更好的方法吗？特别是，当我切换到更新的内核时，是否有一种方法可以使生活更轻松？
答案 0 :(得分：2)
我认为清理你当前的设置并不容易，除非你的历史相当短，但我会建议：
设置一个主存储库，其中包含为代码来自的其他每个地方设置的远程数据库 - 主线内核，补丁，......
专门为驱动程序供应商的更新保留一个单独的分支。
当您获取时，更新不会弄乱您的分支。
当您准备合并时，合并到某种“发布”分支。我们的想法是将每个源与其他源分开，除非需要将其合并。根据此分支进行更改，根据需要合并/重新定位。
这是一个我希望有用的快速图表：
mainline-\----------\-------------------------------\
\ \ /you---\---/-/ \
\release----\-/---/----/-/--------\-/ / --\-----
patches-----------------/---/ / /
/ /
driver-------------------------/--------------/
有这么多分支机构，很难有效地绘制图表，但我希望能让您了解我的意思。 release包含您系统的官方代码，you拥有您自己的修改，driver保存来自驱动程序供应商的补丁，patches保存来自其他一些仓库的补丁，mainline 1}}是主线内核。所有内容都合并到release，您可以根据release进行更改，但只能通过合并每个方向进行互动，而不是直接更改为release。
答案 1 :(得分：0)
我认为普遍接受的最佳政策是 （a）补丁集 （b）主题分支
主题分支基本相同，但经常在主线上重新定位。 Topgit是一个已知的工具，如果您拥有很多主题分支，则可以更轻松地处理主题分支。否则：提前计划并限制分支数量