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

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.