Practice for maintaining multiple Git feature branches simultaneously

I'm relatively new to Git.  I am a sole developer, so I'm trying to keep my Git structures relatively simple, but still effectively utilize Git's features when it makes sense.

I have a situation where I am working on a new feature branch, say v2.0.  That version is currently in QA undergoing testing with no current ETA for test completion.

The client now wants new functionality relatively urgently, which I'm going to setup on branch v3.0.  But at this point, I don't know for sure if the v2.0 release will be deployed to production before the client chooses to release v3.0.

So I'm going to have to maintain two feature branches and don't yet know which will release first.  Is there a process or best practice to maintain the branches in Git in this scenario?

I'm currently guessing that it makes sense to have a separate v3.0 branch that is not dependent upon v2.0.  Is that the best approach?

master <-- v2.0
master <-- v3.0

I would therefore code v3.0 without any of the v2.0 changes present, assuming that v2.0 won't be released first.  If v2.0 does get released first, then I'll have to quickly merge all of the v2.0 changes into v3.0.

Open to feedback.
LVL 19
Steve EndowMicrosoft MVP - Dynamics GPAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Franck HorlavilleTechnical DirectorCommented:

I would suggest you use the gitflow branching model

- each new feature is in a feature branch (which are name according to what they do, not version numbers)

- when a feature is ready, merge it into the develop branch

- deploy to test from the develop branch

- when ready to go live, create a release from the develop branch with a version number and push to master

- deploy to production from master

I use SourceTree to make this process extremely easy and painless

Here's a nice tutorial:


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Steve EndowMicrosoft MVP - Dynamics GPAuthor Commented:
Thanks for the response and the link to that article. I had read the source article by Vincent Driessen, but I didn't see the relevance of his workflow model for my simple needs.

But the Atlassian overview makes more sense to me and seems more relevant.  Creating a Release branch off of Dev makes sense.

I have two follow up questions if you don't mind.

1. How do I create the Develop branch for a new project?  Just immediately create the Develop branch as the first step for every new project, and always branch off of Develop for new feature branches? (probably an obvious question/answer, but just want to confirm)

2. Even with the Develop + Feature + Release branch workflow model, if I have a situation where I don't know whether branch Feature Set A or separate branch Feature Set B is going to be released first, I will have to maintain those two feature sets as completely independent branches, and then ultimate perform a merge with the branch that is released later, correct?

So if Feature Set B gets released first, I'll need to:

1. Merge Feature Set B changes into the Develop branch
2. Create a Develop build to Test
3. Create a Release branch from Develop for Feature Set B
4. Merge Release branch into master
5. Create a master build for deployment to Prod
6. Merge any changes in Release branch back into Develop
7. Merge the Develop branch changes into Feature Set A branch

I think I get the idea, but the Release branch is probably overkill for my very simple needs.

I'll think more about using the Development branch.  At the moment, I just create feature branches off of master, since most of my projects are very linear.


Franck HorlavilleTechnical DirectorCommented:
If you're on Mac or Windows, SourceTree makes it really painless.

To answer your questions:

1. Your first commit is to the master branch. Your second action is to initialise git flow. If on the command-line, that's
git flow init

Open in new window

This will create the develop branch for you.

2. The git flow extension (or SourceTree) makes the process easier:

git flow feature start A

Open in new window

Commit, commit, commit
git flow feature start B

Open in new window

Commit, commit, commit
git flow feature finish B

Open in new window

At this point B is merged into develop
Deploy develop to QA.
git flow feature start bug-fixes

Open in new window

Commit, commit, commit
git flow feature finish bug-fixes

Open in new window

Deploy develop to QA, repeat until QA is ok.
git flow release start v1.0.0

Open in new window

Do only the changes needed for a release, such as updating version numbers
git flow release finish v1.0.0

Open in new window

Deploy master to production
At this point master and develop are in sync.
If any bug appears on live
git flow hotfix start typo

Open in new window

git flow hotfix finish typo

Open in new window

Deploy master to production

When you need to add new functionality, you start by
git flow feature start C

Open in new window

And you repeat.

Master will contain the history of your production server and develop will have the history of all your code.

If at one point in the future you need to implement A, just checkout feature/A, pull develop into it to update it with the latest runnable code, fix any conflicts and go on from there, finishing feature A when ready to include it in develop

As a rule of thumb, only finish features when they execute properly and pass their tests. Develop should only contain production-ready code.

Is it clearer detailed in this way?

Steve EndowMicrosoft MVP - Dynamics GPAuthor Commented:
Thanks Franck.  This is helpful.

I am using Visual Studio 2013 with the native Git support, and it doesn't currently support several Git features, such as "flow init" (I hadn't heard of that before).

The Visual Studio interface for Git is not great, so I may have to try SourceTree.  I have SourceTree installed, but I haven't actually used it.

I'll take a look at SourceTree and also dig into Git commands more.  While the Visual Studio Git support is convenient, it is clearly lacking some valuable functionality.


It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Version Control

From novice to tech pro — start learning today.