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.

Cacilie

To me this looks more like you need to think about your features and branches instead of fixing it with scripts. Dependent features are already a sort of smell. Finish on branch first, get it integrated and then start working on something new. I know this sounds easier than it is, but is the best solution. – Clearway

I can see you could find some smell in the notion of dependent features. I guess this comes from having fallen too deeply in love with git's way of providing possibility for editing my [not yet published] commits; I do not like pushing bad stuff for others to see, and I like to keep the final history look clean (e.g. for the sake of code reviews). On the other hand, I think having more flexible tools allows having more flexible work flows; natural support for dependent private branches would make my work easier in my current development contexts. – Cacilie

I don't see how the ability to rebase branches has any impact on "get one thing done, then work on the next". – Clearway

One recent example of "dependent features": automatically generated code (from data description language); to fulfill a functional requirement I need to extend the facility. For representational clarity I am developing the general support and one of the functional requirements in separate branches. The latter works as a test case for the generic support (other similar requirements to be implemented in their own branches once the generic support proved to be working). Then I might have various personal debug annotations or experiments that I maintain in private branches. – Cacilie

git is powerful tool and supports different ways of organizing your workflow. This is just one that I am personally missing and maybe end up implementing to cure my itching, but wanted to know first if something already exists. – Cacilie

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

Brittenybrittingham

I cannot just change the work flow of my organization. I agree perfectionism/procrastination is something to question - especially if detected as a habit. But this was/is just one (minor) reason for having such lingering private branches. Conceptually speaking I was missing something like private layers to public code (which are technically just patches, and can be implemented as local branches). – Cacilie