When to branch in git?

Question

I've just started using git and while it is relatively easy to find out how to do something with git I'm having trouble figuring out when to do something with git.

For instance, when does one usually branch a project?

I was thinking of branching each version of a current project and when it's complete merging it with the master - is that common practice?

Answer 1

I am sure there are people who do things different to what I do. However, this is what I follow:

• Always create a branch for each feature (merge them back later)
• Create a branch for each bug fix
• Let the master branch be clean by not making it a Work In Progress (WIP)

Answer 2

I am not sure what you mean by branching each version of current project.

Anyway, git advices that you create 'topic branch'. By 'topic branch', it means that you create a branch when you are working on a feature/bug. Let's say I am working on jQueryUI and I have been asked to add a feature to jQuery Calendar which allows user to specify dates which are not selectable.

If I am in branch named master, I will create a local branch named 'SpecifyDateExclusion' branch and start making my changes. Any and all the code related to this feature will go in this branch.

master
  |
  |
  |___ SpecifyDateExclusion

While I am working on this feature, a bug report comes that calendar is broke in Opera 10 and this bug needs to be fixed now. I go back to my master branch and create another branch named Opera10BugFix and start fixing bug in it.

master
  |
  |
  |___ SpecifyDateExclusion
  |
  |
  |___ Opera10BugFix

Very soon, you may have branches like

master
  |
  |
  |___ SpecifyDateExclusion
  |
  |___ Feature1
  |
  |___ Feature2
  |
  |___ Feature3
  |
  |___ Opera10BugFix
  |
  |___ BugFix1
  |
  |___ BugFix2

What's the advantage you may ask?

The advantage is the flexibility it gives me while preparing my release. Let's say my next release is mainly about bug fixes.

I will create a new branch named 'InterimBugFix' from master and merge all my bug fix branches.

If I want to create a mix of bug/feature release, I will create a branch named 'NextVersion' from master and merge my feature/bug fixe branches.

Git is extremely powerful about how you manage these branches and if you can imagine something, Git will let you do it.

Answer 3

There are many answers to this depending on your "branching strategy". The 2 simplest (in my experience) are task/feature branches and release branches. Which you use will depend on how your release cycle works, among other things.

If you are integrating and releasing continuously then task/feature branches make sense, as they leave the "master" (trunk in other VCS) in a relatively stable state, making releases easy. But if you have a more structured release cycle, maybe release branches will make more sense as they can be used to more carefully define what gets added to each release. Of course, a hybrid strategy is also feasible.

I usually use task/feature branches, so every bug or feature request is branched. Then is worked on and, when complete, merged back into the master.

Answer 4

The best thing about Git is that it doesn't force any decisions on to you. The worse thing about Git is that it doesn't force any decisions on to you.

Your workflow is entirely up to you. Are you intending to collaborate, or are you developing independently? Do you have a short or long lead time between releases? These constraints might help to define a suitable workflow.

I work in a small team of 4 developers with a two week iteration cycle. At the start of the cycle we agree on a scope and develop against master. Anything that we expect to exceed the two weeks is moved (or starts life) in a branch (This doesn't happen often, our scope is tight).

At the end of the two week cycle, we perform our QA, tag and release. Starting the next cycle, those other branches are merged back in to master.

If you need to patch a release, we create a branch, commit, QA, tag and release.

For anything experimental, we'll generally create a new branch and keep it isolated from master until it's suitable to be merged in, or discarded.

In summary, our team branches when:

• Features exceed our iteration cycle
• Patch a release
• Experiential features

Our workflow is very centralised, and probably not typical of many Git users. Neither is right or wrong, it's just about picking what's the most suitable.

Answer 5

In Web Application Development, we do this:

We maintain a pristine branch called "Production". It contains the code that exists on the live websites.

Any changes to that happen in Task branches. So you may see a branch Task-13923-add-feature-x. These branches are created from the production branch and the production branch must be merged into them before merging into production (so it is always a clean fast forward, no potential conflicts).

Everyone else merges the "Production" branch from time to time into their task branches to stay up to date.

Answer 6

When in doubt, branch. Branches are cheap, and information from new branches can easily be transferred to old branches. When a branch has outlived its usefulness, it can easily be killed.