What's your ideal branch architecture within git for web applications?

Question

We're a small team of developers and building a web application. We're currently having a live, testing and several development environments.

What branch architecture would you suggest, so ideally each developer can work on his feature(s), these can be tested and deployed without tangenting other developers/features?

Currently, each developer has its own development branch and rebases into the testing branch. As soon as a feature is approved, the developer rebases his changes into the master.

This works as long as the features are tested immediately. However, if one developer is working on the next feature while the feature before is still tested, we need to handle things manually.

Thanks for opinions.

score 3 · Accepted Answer · answered Jul 06 '11 at 14:20

3

It has been a while that I follow this useful guidelines described by Vincent Driessen in his article A successful Git branching model.

You can take a look there and you will see how he describes the branches management and avoid rebases

answered Jul 06 '11 at 14:20

Felipe Sabino

17,825
6
78
112

2

Vincent's model seems better suited to a desktop application with infrequent releases than for a web application with frequent releases. – claymation Mar 08 '12 at 19:50
I have to disagree as I use this approach for mobile and web app and I can't see a link between his approach and the release frequency you have. Where would the frequency be an issue? – Felipe Sabino Mar 08 '12 at 22:27
@FelipeSabino I had the same initial impression as claymation. And I didn't understand whether release branches make sense when you're putting out new code every day or two, and where you're not thinking in terms of releases from a project management perspective. Also. in that situation, do you have a single ongoing release branch, or you do literally create a new release branch no matter how small/trivial the "release"? – Chris Sep 20 '13 at 18:41
@Chris If you have too much support preparation every new production release to the point that you have too much trouble from create release branches to the time you are ready to release, then I thing your problem is not git related and you could solve it with some continuous integration tools like `Travis CI` or `Jenkins CI`. – Felipe Sabino Sep 23 '13 at 21:01

score 0 · Answer 2 · answered Oct 27 '14 at 21:17

This slidedeck (created after the OP and answer) was very helpful when I was exploring options, essentially recommends each developer branches from a single develop branch, and then pushes back there and rebases regularly for latest changes (caveats included).

user229044 · Answer 3 · 2011-07-06T14:20:58.963

I assume you're working with a centralized bare repository where everybody is pushing their changes, and then you're pulling the latest testing branch into the test environment.

Why not use Git as an actual DVCS and simply pull features from each user into the testing environment as the testing of the previous feature is finished?

If Bill is developing FeatureX, and Ted is developing FeatureY, they could make their features available on branches called testing/feature-x and testing/feature-y respectively, and you could simply checkout bill:testing/feature-x in the testing environment.

Failing all that, using multiple testing/feature-name-here branches would solve your problem in a traditional centralized system. Just have your users push their testing/... branch to the central repo, pull them into the testing environment, remove the branch when it has been tested. You can always see a list of features waiting to be tested by examining all the branches prefixed with testing/. If a feature's testing fails, you have a centrally located branch specific to that feature where you can add new commits to fix the feature before it is retested.

What are you doing now if a feature fails testing, after rebasing the feature onto the only testing branch? What if somebody else has rebased their feature for testing onto the branch which now contains a broken feature?

score 0 · Answer 4 · answered Mar 08 '12 at 19:51

For a web application, you're (hopefully) deploying working code daily, so you'll probably find a single branch (master) to be adequate. Use continuous integration/deployment, write good tests, and design your features to be released in small doses instead of all at once.

What's your ideal branch architecture within git for web applications?

4 Answers4

Linked