用于保持要素分支历史记录的Git工作流

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

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

主要的问题是，有时功能在最初实现后的几周/几个月内就得到了修复/调整，有时这种情况会重复几次，因此普通的“功能分支工作流”将无法正常工作

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

这里有两个我们能够想到的选择，我将只描述如何处理上面有问题的场景，因为这是导致复杂的唯一原因

方法A 初始状态：功能的第一个/上一个版本位于分支X上，最后一次更改是在几个月前，并合并为主版本

git签出X；git合并--无ff主机

进行更改并提交

git签出主机；git-pull；git merge——没有FFX；git推送

然后，

git log——第一个父级——no merges

显示了从一开始就在这个分支上完成的提交的一个很好的列表

这种方法的主要问题在于其脆弱性和限制性：

• 如果有人在步骤1中使用fast forward进行合并，则使用上述方法 因为检索历史记录之后将不起作用。好了，不可能有任何ff 被迫回购，但每个人都必须这样做，不要忘记
• 在第3步中重新设置基础，然后进行合并，这也将打破历史，许多人都喜欢这种方法和重新设置基础。可能是 完全禁止重订更安全，但我不知道如何强制执行 它

方法B 每次有人回到功能X上工作时，他都会创建一个新的X_修复，X_更改，等等

缺点：分支列表难看且杂乱无章，需要编写脚本来生成提交列表

目前，我们在被子里保留了一套补丁。虽然这完美地解决了上述问题，但在其他方面却非常丑陋

---

有（更好的）想法吗？

你能详细说明一下为什么你认为重新定基不合适吗？我理解它的破坏性，但如果一次只有一个人处理某个特定功能，这应该不会是一个问题。我不知道会发生什么，但如果在第3步中完成合并前重定基址，那么git log命令将不再生成X提交列表，他们和其他人混在一起。你能详细解释一下为什么你认为重定基期不合适吗？我理解它的破坏性，但如果一次只有一个人处理某个特定的功能，这应该不会是一个问题。我不知道会发生什么，但如果在第3步中完成合并前重新定基，那么git log命令将不再生成X提交列表，它们与其他提交混合在一起。