CODEWITHSUNDEEP
git
pavel_kazlou
pavel_kazlou

Reputation: 2046

git branching for maintaining several releases

I'm considering the way to manage branches in git repo at our project. I've read famous article and really liked the idea and it seems this model should be useful for us.

However, there is a hidden assumption in the article, which comes from the existence of master branch: the latter the release, the greater its version. For example 2.0.1 is released always after 1.5.10. So when you traverse each commit in master the version will always increase.

This doesn't hold true for our project case. We have to maintain several version for different customers. For one customer we have to support (and deliver fixes) for version 1.5, for another customer the version is 2.0. Obviously version 1.5.10 in our case can come latter (in terms of time) than version 2.0.1. Committing 1.5.10 into master after 2.0.1 was committed makes no sense.

Is article's model not suitable for us at all, or can we modify it a little bit to make it work?

Upvotes: 0

Views: 59

Answers (2)

lig
lig

Reputation: 3890

It is known practice to have different branches for corresponding major releases.

master still stands as main integration branch.

Than you should maintain your release branches separately and decide which commits you want to deliver to every release branch.

It is always good to look into famous projects you know to adopt your release model and learn their repository policies. Here is the good example of maintaining several major releases using git scm https://github.com/django/django/branches

Upvotes: 1

Daniel
Daniel

Reputation: 3806

Master should reflect the current version only, that is how I've implemented it. Any other version is on its on branch.

E.g

V1 (master) -> -> -> \/ -> V2 (master)
     v2  -> -> -> -> /\ -> V1 (no longer master)

Commits on branch V1 is no longer part of master history and V2 history has merged with master. So no history should conflict in your logs.

Upvotes: 0

Related Questions