Is there any harm letting a git branch "grow old"?

Question

So I've heard of the branch-per-feature workflow using Git, and I've also read some reasons why this could be a bad idea.

My real question is this - if I'm developing just a small feature (like a simple regex time parser), after merging this branch back into the trunk, what happens (or should happen) to that branch? Does it just sit there? Since I created it for that one, very specific feature, I can't think of a reason I'd have to go back and use the branch. Should I somehow mark this branch as defunct, or do I just move on and forget about it?

Thanks

Answer 1

When I use feature branches, I like to retain the fact that a feature was developed in a branch after the merge. That makes browsing the history much easier. It groups changes by feature or bug and makes it easier to know the most important thing: why a change was done.

Which is why when I merge, I deliberately disable fast forwarding with git merge --no-ff. This retains the structure of the branch in history. Then I'm free to delete the branch label (git branch -d branch_name), the merge point contains the branch name, and clean up the set of branches.

In contrast, when working on a branch I prefer to rebase the upstream branch. This keeps the history of the branch nice and clean, free of lots of upstream merge noise and conflict resolution. I will generally rebase upstream before merging to make the job of integrating easier (as the branch author I can fix conflicts and broken tests) and the resulting merge cleaner.

This approach retains the history of the branches while preventing old branches no longer being developed from clogging things up. It makes visualizing the history with gitk or GitX very useful.

I agree with the basic points in the article you linked, as you get more and more large feature branches which are worked on simultaneously there's more and more chance of conflict and integration problems. The isolation which makes them so useful becomes a liability. One of the solutions is to not have large, old feature branches. If you can bust a feature branch up into smaller pieces which can be completed and integrated, then you avoid the problem. This is often useful for many other reasons, like the poor slob that has to review the code.

If it is possible to continuously integrate a feature branch into mainline, then the feature branch must have useful, working, tested, documented work. If it has that, then those could be sliced off into their own branches.

I freely admit I may be reading too much into this, but one of the possibly telling flaws in the article is that the branches are named for people and not features. This implies that each branch is for "whatever Jim is working on" rather than "adding blue widgets". It implies a number of developmental problems...

• features and branches are owned by individuals or teams
• branches are not for discrete features
  • instead, branches are personal playgrounds
  • with no defined feature, they can go on and on
• development is done in silos
  • individuals do not speak to each other regularly
  • individuals do not work together on branches
  • individuals do not talk about their changes until integration

A lot of this is not a technical problem but a social problem. Much of it can be solved by strong use of a good issue tracker strongly linked with version control, such as Github's. The main change is:

• branches should be for defined features
• developers should report an issue before going off and doing a bunch of work
• nobody "owns" a feature (though they may be responsible for it)

That second one is, unfortunately, discouraged by most project's bug tracking policies. The urge to have a patch ready before reporting a bug is a very strong one.

Good branch management requires good socialization which is facilitated by a good issue tracker with strong version control integration and a welcoming policy.