尝试从http://nvie.com/posts/a-successful-git-branching-model http://nvie.com/img/2009/12/Screen-shot-2009-12-24-at-11.32.03.png开始坚持分支模型 ，即使用特征分支并将它们合并回开发分支，我有时会遇到以下情况：
功能base（既是功能分支又是Python包）被认为是完整的并合并到develop中。现在，需要stuff的功能（=分支和包）base已经分支，在开发过程中，我意识到stuff需要在base中进行一些修改/增强应该从一开始就在那里。那么我应该在哪个分支中修改包base？
stuff中执行此操作似乎是错误的，因为base的修改应该成为dev的一部分，无论何时（和如果）stuff合并回来。< / LI>
base，修改，合并到develop和stuff将另一方面创建许多合并，我不确定这是否是一个好习惯将合并到功能分支中。特别是如果它只是一个次要但重要的修改git cherry-pick）也感觉不对。base转换为git submodule听起来有点矫枉过正stuff重新定位到更新后的develop会使历史记录看起来更好，但如果其他人撤回原始分支stuff会导致常见问题 - 这不是我的单一开发人员案例中的问题，但这个问题的可能性仅仅表明我正在做一些更根本的错误...... 答案 0 :(得分：0)
根据https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html的“规则：主题分支”，建议似乎是
- 如果您发现需要其他分支机构的新功能继续处理您的主题，请将其他功能合并到主题。 （但是，不要“习惯性地”这样做，见下文。）
其中“下方”读取
规则：仅在明确定义的点合并到下游
除非有充分理由，否则不要合并到下游：上游API 变化影响你的分支;您的分支机构不再合并到上游 干净;等
否则，合并到的主题突然包含多个 单一（分离良好）的变化。由此导致的许多小合并将会出现 大大混乱了历史。任何后来调查历史的人 一个文件必须找出该合并是否影响了该主题 开发中。上游甚至可能无意中被合并为一个 “更稳定”的分支。等等。
总之，这意味着“将base合并到stuff iff必需，但永远不要将develop合并到stuff中（因为它可能包含其他功能）与stuff）“