我很快就开始维护一系列包含相同嵌入式软件变体的产品。由于我已经使用 git 一年了并且非常欣赏它，所以我很可能使用它来进行源代码控制。
我可以看到多种用于维护固件变体的选项，但没有一个让我太满意。您在自己的工作中应用了哪些最佳实践？
我能想到的替代方案：
defines。预处理。
优点：所有内容都始终存在于源代码中，很难错过其中一款产品的更新。
缺点：较难阅读。当我们只有两个变体时可能还好，当它变成四个或更多时，那就很痛苦了。而且，应用 DRY 原则（不要重复自己）似乎更困难。
每个产品变体一个分支。
当包含适用于所有产品的更改时，必须将更改合并到其他产品。
缺点：如果提交包含所有产品的更改和特定变体的更改，则会出现问题。当然，您可以确保提交仅包含一种更改：此产品更改或整个系列更改。但尝试将其强加给团队？另外，合并是行不通的，我们应该精挑细选。正确的？
a 核心存储库作为子模块。
将包含核心功能的所有文件单独作为存储库。
所有产品都包含核心存储库的一个版本作为子模块。
缺点：我看不出最终不会有核心子模块的变体。然后我们又遇到麻烦了，然后我们又会使用定义或一些不好的东西。
有分支的核心存储库？然后我们回到之前的选择：必须合并适用于所有分支的更改，但合并还包括产品特定的内容。
create 每个模块一个存储库。
例如，显示驱动程序的存储库、电源管理硬件的另一个存储库、用户输入接口的另一个存储库……
优点：良好的模块化。只需选择您需要的模块作为子模块即可制作新产品！所有子模块都可能有分支，例如一个变体以不同的方式使用硬件。
缺点：有很多很多模块，每个模块都跟踪几个文件（一个包含文件和一个源文件）。一个麻烦。
有人在某些模块中进行了重要更新？然后，如果合适的话，需要有人将更改包含在该模块的其他分支中。然后有人还必须更新每个产品存储库中的子模块。
做了相当多的工作，但我们有点失去了 git 的快照功能。
你是如何做到的，效果如何？或者你会怎么做？
我有一种感觉，我应该体验一下樱桃采摘。
您应该尽可能努力将每个变体的自定义代码保留在其自己的文件集中。然后，您的构建系统（Makefile 或其他文件）根据您正在构建的变体选择要使用的源。
这样做的优点是，在处理特定变体时，您可以看到它的所有代码，而不会出现其他变体的代码造成混淆。可读性也比在源代码中乱七八糟地使用 #ifdef、#elif、#endif 等要好得多。
当您知道将来想要合并时，分支效果最好all将代码从分支转移到主分支（或其他分支）。它不适用于仅合并some从一个分支到另一个分支的更改（尽管这当然可以完成）。因此，为每个变体保留单独的分支可能不会产生好的结果。
如果您使用上述方法，则无需尝试在版本控制中使用此类技巧来支持代码的组织。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
