最近，我似乎有一个重复的场景，即有多个正在开发的功能分支，其中一个功能分支(下图中的feature-b)取决于对另一个未完成功能(在feature-a中开发)的支持：
---o---o--o master
|
+---o---o---o feature-a
|
+----o---o feature-b
每当我修改feature-a(包括交互式重定基以修复特性中的错误)时，我都需要将feature-b重定基到feature-a上。这些都是本地分支机构，所以我可以随心所欲地修改它们。
我经常遇到以下情况：
master testing
---o---o--o-------------------------------------------o---o
| feature-a . .
+---o---o---o . .
| feature-b . .
+----o---o ..................... .
| feature-c .
+----o---o .......................
其中，测试分支是正在开发的所有(相关)特征的组合，通过合并其上的所有相关特征分支产生(在图片master、feature-b、feature-c中，隐含feature-a)。
目前，特别是如果有更复杂的功能分支关系，我会不断打开gitk来可视化分支关系，并维护shell脚本来自动重新建立基础，但这种方法似乎很脆弱，而且通常很麻烦。我想知道的是：
- 是否有一种方法可以描述甚至自动检测分支关系，然后用一个命令尝试重新强制执行所描述的关系[在上面的简单示例中，通过重新定基或向头添加新的提交来更改
feature-a后，在feature-a的新头上自动重新定基feature-b] - 用于将一组分支重定基准到其他提交的GUI工具(如果冲突会阻止操作，则只需给出错误即可)
- 管理这个分支机构混乱的其他想法？所涉及的意外复杂性成本太高时间和消耗太多的脑力
我不喜欢把不好的东西推给别人看，我喜欢保留决赛历史看起来是清白的。
这是个坏习惯。您应该为"建议的更新"保留一个master和pu。将您的提交推送到pu，然后根据需要将pu重定为master。时机成熟时，您可以从pu中挑选，甚至可以将pu合并到master中。
git-reo本身就是这样做的。避免掉进无休止的树枝"兔子洞"。
相关