Managing dependent in-progress git feature branches / branch sets

Question

In recent times I seem to have this repeating scenario of having multiple feature branches under development, with one feature branch (feature-b in the below picture) depending on support of another incompleted feature (developed in feature-a):

---o---o--o                    master
       |
       +---o---o---o           feature-a
                   |
                   +----o---o  feature-b

Whenever I modify feature-a (including interactive rebasing to fix errors in the feature), I need to rebase feature-b onto feature-a. These are local branches, so I am free to modify them how ever I want.

More often I have the following kind of case:

             master                                         testing
---o---o--o-------------------------------------------o---o
       |              feature-a                      .   .
       +---o---o---o                                .   .
                   |           feature-b           .   .
                   +----o---o .....................   .
                   |           feature-c             .
                   +----o---o .......................

where testing branch is combination of all the (related) features under development, produced by merging all the relevant feature branches on it (in the picture master, feature-b, feature-c – and by implication feature-a).

Currently, especially if having more complicated feature branch relationships, I have gitk constantly open to visualize the branch relationships, and maintain shell scripts to do this rebasing automatically, but this method seems fragile and a general nuisance. What I would like to know:

1. Is there a way of describing and even automatically detecting the branch relationships, and then with one command try to re-enforce the described relationship (in the above simple example, after changing feature-a by rebasing or adding new commits to the head, perform automatically rebasing feature-b on the new head of feature-a).
2. GUI tool for rebasing a set of branches onto other commits (simply giving error if a conflict would prevent the operation would be okay)?
3. Other ideas of managing this branch mess? The accidental complexity involved is costing too much time and draining too much brain power.

Answer 1

I do not like pushing bad stuff for others to see, and I like to keep the final history look clean.

This is a bad habit. You should keep a master and a pu for "proposed updates". Push your commits to pu and then rebase pu onto master as necessary. When the time is right you can cherry pick from pu or even merge pu into master.

This is how it is done with the git repo itself. Avoid falling "down the rabbit hole" of endless branching.

related