跟踪源代码变体 [英] Keeping track of source code variants

问题描述

我很快开始维护一系列包含相同嵌入式软件变体的产品。由于我一直在玩git一年，非常感谢，我可能会使用它进行源代码管理。

有几个选项我可以看到为了维护固件的变体，但没有什么比我更喜欢我。你最适合自己的工作是什么？

我可以想到的替代方案：

• 定义。预处理。
  优点：一切都始终存在于源代码中，更难错过其中一个产品的更新。
  缺点：难以阅读。可能我们只有两个变体，当它变成四个或更多时，这将是一个痛苦。此外，似乎更难应用干性原则（Do Do Repeat Yourself）。




• 每个产品变体一个分支。
  当包含适用于所有产品的更改时，必须将更改合并到其他产品。
  缺点：如果提交包含所有产品的更改和特定变体的更改，则会出现问题。当然，您可以确保提交仅包含一种更改：此产品更改或全系列更改。但是试图强加一个团队？此外，合并将不起作用，我们应该是采摘。




• 一个核心存储库作为子模块。
  使包含核心功能的所有文件都是独立的存储库。
  所有产品都包含核心版本库作为子模块的版本。
  缺点：我看不到最终不会有核心子模块的变体。然后我们再次遇到麻烦，然后我们再次使用定义或不好的东西。
  一个分支机构的核心仓库？然后我们回到以前的替代方案：适用于所有分支机构的更改必须合并，但合并还包括产品特定的内容。




• 创建每个模块的存储库。
  例如用于显示驱动程序的存储库，另一个用于电源管理硬件，另一个用于用户输入界面，...
  优点：良好的模块化。通过将所需的模块作为子模块来制作新产品！如果例如变体以不同的方式使用硬件，则所有子模块都可能具有分支。
  缺点：很多模块，每个都跟踪几个文件（包含文件和源文件）。一个麻烦
  有人在某些模块中做了重要的更新？那么有人需要在这个模块的其他分支中加入更改。那么有人也必须更新每个产品库中的子模块。
  有一些工作，我们会丢失git的快照方面。

你怎么做，它是如何工作的？或者你会怎么做？

我有一种感觉，我应该有经验的樱桃采摘。

解决方案

我尽量尝试去 #define 。使用适当的代码，您可以最大限度地减少对可读性和重复的影响。

但同时 #define 可以安全地结合分裂和分支，其应用取决于代码库的性质。

I am soon starting to maintain a line of products containing variants of the same embedded software. Since I've been playing with git for one year and appreciate it very much, I'm likely to use it for source control.

There are several options I can see for maintaining the variants of the firmware, but none pleases me too much. What are the best practices you apply for your own work?

Alternatives I can think of:

• defines. Pre-processing. Pros: everything is always present in the source code, it is harder to miss the update of one of the products. Cons: harder to read. It might be ok while we have only two variants, when it becomes four or more it will be a pain. Also, it seems harder to apply the DRY principle (Don't Repeat Yourself).

• one branch per product variant. When changes that apply to all products are included, the change must be merged to the other products. Cons: if a commit contains both changes for all products and changes for the specific variant, there will be trouble. Of course, you can make sure that a commit contains only one kind of change: this-product-changes, or the-whole-family-changes. But try to force that on a team?? Plus then merging wouldn't work, we should be cherry-picking instead. Right?

• a core repository as a submodule. Make all files that contain core functionality a repository on its own. All products contain a version of the core repository as a sub-module. Cons: I can't see that there wouldn't eventually be variants of the core submodule. Then we're in trouble again, and then we'd use defines or something bad again. A core repository with branches? Then we're back to the previous alternative: a change that applies to all branches must be merged but merging includes also the product specific stuff.

• create a repository per module. For example a repository for a display driver, another one for the power management hardware, yet another for the user input interface, ... Pros: good modularity. Make a new product by just picking up the modules you need as submodules! All submodules might have branches, if for example a variant uses the hardware in a different way. Cons: Lots and lots of modules, each keeping track of a couple of files (an include file and a source file). A hassle. Someone makes an important update in some module? Then someone needs to include the change in the other branches of this module, if appropriate. Then someone must also update the submodule in every product repository. Quite some work, and we kindof lose the snapshot side of git.

How do you do it, and how has it been working? Or how would you do it?

I have a feeling that I should get experienced with cherry picking.

解决方案

I'd try to go for #defines as much as possible. With a proper code you can minimize the impact on readability and repetitions.

But at the same time #define approach can safely be combined with splitting and branching, application of which depends on the nature of the codebase.

这篇关于跟踪源代码变体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！