Python 如何正确处理功能分支和包的相互依赖关系？

在尝试从[
，即使用功能分支并将其合并回开发分支，有时会遇到以下情况：

功能

base

（同时是功能分支和Python包），被认为是完整的，并合并到

develope

。现在是功能（=分支和包）

stuff

，它需要

base

，是一个分支，在开发过程中，我意识到

stuff

需要在

base

中进行一些修改/增强，这些从一开始就应该存在。那么我应该在哪个分支中修改包

base

• 在分支

  stuff

  中这样做似乎是错误的，因为无论何时（如果）

  stuff

  被合并回来，对

  base

  的修改都应该成为

  dev

  的一部分
• （重新）分支到

  base

  ，修改，合并到

  develope

  和

  stuff

  中，另一方面会创建许多合并，我不确定合并到功能分支中是否是一个好的做法。特别是如果这只是一个小而重要的修改
• 而且两次提交（通过git cherry pick）也感觉不对
• 将

  base

  转换为

  git子模块

  听起来有点过头了
• 在更新后的

  develope

  上重新设置

  stuff

  会让历史看起来更美好，但如果其他人删除了原始分支

  stuff

  ，则会导致通常的问题-在我的单个开发人员案例中，这不是一个问题，但仅仅是这个问题的可能性就表明我犯了更根本的错误

根据的“规则：主题分支”，建议如下

• 如果您发现需要“其他”分支的新功能来继续处理您的主题，请将“其他”合并到“主题”。（但是，不要“习惯性地”这样做，请参见下文。）

其中“下方”为

规则：仅在定义明确的点处合并到下游 除非有充分的理由：上游API，否则不要合并到下游 更改会影响您的分支；您的分支不再合并到上游 干净的；干净的

否则，合并到的主题突然包含多个 单个（分离良好的）变更。许多由此产生的小型合并将 把历史弄得乱七八糟。以后调查历史的人 一个文件的管理者必须找出合并是否影响了主题 在开发过程中，上游甚至可能无意中被合并为 “更稳定”的分支。等等

总之，这意味着“必要时将

base

合并到

stuff

中，但决不要将

develope

合并到

stuff

（因为它可能包含与

stuff

无关的其他功能）。”