用于保留功能分支历史记录的Git工作流程

Question

在我们的项目中，我们正在上游软件（U-Boot）之上实现功能。每隔一两年，就开始开发一种新硬件，并以更新版本的上游软件为基础。以前实现的一些功能几乎适用于新项目，没有太多修改。

因此，我们需要一个工作流程，允许跟踪和重用在特定功能范围内完成的工作，而无需从整个代码库中删除它。它不应该是完美的，因为它不经常需要，但也不应该是痛苦的。

主要问题是有时功能在初始实施后的几个星期/几个月内被修复/调整，有时这会重复几次，因此可以使用分支工作流程＆＃34;不会按原样工作。

团队和代码库都相对较小（约5人，分别在上游代码之上约15 LoC）。通常一次只有一个人处理特定功能。

以下是我们能够提出的两个选项，我只会描述处理上述问题的情况，因为它是唯一的并发症来源。

方法A

初始状态：功能的第一个/上一个版本在分支X上，几个月前最后一次更改并合并到主人

1. git checkout X; git merge --no-ff master
2. 进行更改并提交
3. git checkout master; git pull; git merge --no-ff X; git push

然后git log --first-parent --no-merges显示了从一开始就在这个分支上完成的一个很好的提交列表。

这种方法的主要问题是它的脆弱性和限制性：

• 如果有人在步骤1中与快进合并，则采用上述方法 检索历史后不再工作。 AFAIK --no-ff可以 强迫回购水平，但每个人都必须这样做而不要忘记。
• 第3步中的rebase-and-then-merge也将打破历史，很多人都喜欢这种方法和一般的变基。可能是这样的 更安全地禁止变革，但我不知道如何执行 它。

方法B

每当有人回到功能X上工作时，他就会创建一个新的X_fix_this，X_change_that等。

缺点：丑陋且杂乱的分支列表，需要编写脚本来生成一个提交列表。

目前我们在被子中保留一组补丁。虽然这完全解决了上述问题，但在其他方面却非常难看。

任何（更好的）想法？