CODEWITHSUNDEEP
gitbranching-and-merging
kuskmen
kuskmen

Reputation: 3775

Multi-branching model

currently I have a task about branching model I should use. Right now I have master branch and I am branching release branches from time to time to release branches about new features. This is how it looks my branching model right now.

master
|
|---- release 1.0 branch
|   |
|   |
|   |
|   |----- *(1) needed branch
|   |    |
|   |    |
|   |    |
|   |    |
|----    |
|---------
|
|---- release 1.1
|   |
|   |----- needed branch
|   |    |
|   |    |
|   |

*(1) - Each time release branch is closed for features I make new feature branch and then merge this("needed branch") just before next release.

Few questions that might come up reading this.

I will edit this as questions are given so I can give the answers in the post

  1. Why you are closing release branch if you need more features? - The thing is I need to have stable branch(release) at any time after development is "over".

What I want to accomplish?

The problem with this branching model is that I might have a lot of features and each one of them for different client and many of the clients don't want to wait another 1 or 2 weeks until next deploy. I was thinking of making branch for every client and pushing features there and whenever client want to get given feature I can deploy from there without affecting other clients. Cause right now this is impossible. But this is really bad approach since as the clients grow the branches will too.

I want more elegant approach. I understand there will be a lot of questions in the comments so please ask them and lets see if I can answer them and come up with solution or at least an idea.

Upvotes: 0

Views: 290

Answers (1)

ams
ams

Reputation: 25559

It sounds like your problem is not Git: your problem is people. Since these people are paying you, presumably, this seems like the right problem to have!

What I would do is this:

|
* tag:r1
|\______________________
|   \             \     \
|    * feature1   WIP2  WIP3
| __/              |
|/                 |
* tag:r2           * feature2
| ________________/
|/
* tag:r3
|
master

In words, I would do all my releases from master, and all my work on feature branches. When a feature is complete, tested, and a client wants it, only then would I merge to master, retest, and make another release. In this way, master is never in a development state; it's always "just released", or "just about to release" (or idle).

If WIP3 ("Work in progress 3") takes a long time to develop, the graph would evolve like this:

|
* tag:r1
|\__________
|           \
|           WIP3
* tag:r2     |
|\__________ |
|           \|
|            * merge
* tag:r3     |
|\__________ |
|           \|
|            * merge
|            |
|            * feature3
| __________/
|/
* tag:r4
|
master

(I've deleted the feature1 and feature2 branches, now they're merged, but you'd still see the multiple paths in the history.)

If you discover that a client wants a bug fix release to some old version (maybe they paid for support, but didn't pay for new features?), then you can always make a release branch from a tag:

|
* tag:r1
|
* tag:r2
|\_________
* tag:r3   \
|          * bugfix
* tag:r4   |
|          * tag:r2.1
master     |
           release2.x_branch

Upvotes: 2

Related Questions