How to properly treat feature branches and package interdependencies?
Question: While trying to stick to the branching model from
[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)](http://nvie.com/posts/a-successful-git-
branching-model)  
, i.e. using feature branches and merging them back into a develop-branch, I
sometimes encounter the following situation:

Feature `base` (which is both a feature branch and a Python package), is
considered complete and merged into `develop`. Now a feature (=branch&package)
`stuff`, which requires `base`, is branched off and while developing that I
realize that `stuff` needs some modifications/enhancements in `base` that
should have been there from the very beginning. So in which branch should I
modify the package `base`?

  * Doing this in the branch `stuff` seems wrong since the modifications of `base` should become part of `dev` no matter when (and if) `stuff` is merged back.
  * (Re)branching to `base`, modifying, merging into both `develop` and `stuff` will on the other hand create many merges and I'm not sure whether it is good practice to merge _into_ a feature branch. Especially if it's only a minor yet important modification
  * And committing twice (via `git cherry-pick`) also doesn't feel right.
  * Turning `base` into a `git submodule` sounds like overkill
  * Rebasing `stuff` onto an updated `develop` will make history look nicer, but causes the usual problems should others have pulled the original branch `stuff` \- not a problem in my single-developer case, but the mere possibility of this problem suggests I'm doing something more fundamentally wrong...


Answer: As per <https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html>'s
"Rule: Topic branches", the recommendation seems to be

>   * If you find you need new features from the branch other to continue
> working on your topic, merge other to topic. (However, do not do this "just
> habitually", see below.)
>

where "below" reads

> # Rule: Merge to downstream only at well-defined points
>

>> Do not merge to downstream except with a good reason: upstream API changes
affect your branch; your branch no longer merges to upstream cleanly; etc.

>
> Otherwise, the topic that was merged to suddenly contains more than a single
> (well-separated) change. The many resulting small merges will greatly
> clutter up history. Anyone who later investigates the history of a file will
> have to find out whether that merge affected the topic in development. An
> upstream might even inadvertently be merged into a "more stable" branch. And
> so on.

In summary, that would mean "merge `base` into `stuff`
[iff](https://en.wikipedia.org/wiki/If_and_only_if "if and only if")
necessary, but never merge `develop` into `stuff` (since it probably contains
other features irrelevant to `stuff`)"

