GIT flow for every release

[Sebastian Penhouet]

In my company we are about to switch from SVN to GIT. We use GIT-SourceTree-Stash-Jira-Jenkins.

We want to have two main branches for every main version (dev1, release1, dev2, release2,...). Also there are branches for release-candidate, feature, bugfix and hotfix aviable for each of them.

When we start a feature freeze, the developerbranch branches off to an release-candidate. At the final customer release the release-candidate get's merged back into the devoloperbranch and into the releasebranch of this main version.

Now the importaned part: We don't develop on the newest version only. We also develop new features on older releases (and no i'm not talking about customer-adaptations).

That leads to the fakt that everytime we branch off a developerbranch, because the development to come is about a new main version, we need the total git flow (buildin in Stash) working only for that branch.

What i'm trying to say is that we need git flow in stash to work explicit for diffrent branches.

Is it possible to do so?

Edit: It still shoud be possible to merge bugfixes from an older main version to a newer one.

[Johannes Kilian · Accepted solution]

In principle git flow is just a simple convention about different things:

• having a branching model supporting a common developers situation: stable, develop, bugfix, feature and release (and support)
• how to name branches consistently
• for each situation it's clearly defined where a new branch has to start from and where it is merged to ...

That's all ...

To accomplish this in praxis, a set of git-tools has been implemented (also called git-flow). These tools only support the standard situation - not the one you describe....

So the answer: you can use a git-flow like workflow (branching and merging by hand) to do something similar like gitflow does. You cannot use the tools for it ...

Just for correctness: gitflow is not supported by STASH - but by Sourcetree...

[Sebastian Penhouet]

Thanks for you answer. :)

I did notice that Stash doesn't support gitflow like SourceTree does.

That i will have to branch by hand to get the "gitflow" that we want, i already guessed.

But if i do, i can't use the branchingsmodell for naming conventions, can i?

It's still "clearly defined where a new brach has to start from and where it is merged to". So when i use multiple standard branches (dev for main versions) i can't say every "dev" is a standard branch. In consequence of that "dev/3" is not a standard branch and doesn't underlie the same rules or does it?

[Johannes Kilian]

Continuation .... As not more than 2000chars allowed in comment

------

Your approch seems to be a variant/extension of this: you seem to need several "master" branches with the corresponding (git-flow) helper branches. I would suggest to use a decent basename as branchname and derive the corresponding "develop" branchname from this (for example: "version_2_1_x" => "develop_2_1_x"). The helper branches (feature, hotfix and release branches) could use a consistent naming convention for all of your "master" and "development" branches (for example in my setup: all feature-branch names include a reference to the corresponding issue-tracker item: "feature/Issue-1234" - this can be used for your "master" branch as well as your "version_2_1_x" branch ...)

Your approach is needed if you have delivered several variants of your software and you are developing different features on your delivered versions. The standard git-flow approach covers situations when you are developing one main variant of your software (branch "master") and have to do some fixes on older software once in a while (mainly fixing - not developing older versions)...

Not quite sure that your approach is the way to go (several variants of the same software within one codebase) - but I see, that this situation might occur: different customers have different requests on their bought software versions

[Johannes Kilian]

As far as I understood your problem, you have to define your own naming conventions for your "dev" branches.

For example you have the branch "master" where the most current delivered software lives (for example Version 3.0.0). Beside this you have a branch "develop" which is tied to "master" (via gitflow - as development branch for "master") Now you have to do some changes on an "ancient version" of your software (lets say you have to fix version 2.1.2). Usually you branch from your master branch at the point of version 2.1.2.

In most cases this branch isn't considered of equivalent importance as "master" branch (and therefore handled slightly different): the main purpose of this branch is not really further development rather than fixing something on this branch and deliver it again - no further development on this branch until next fix ...

This concept is already part of git-flow convention (but only partly of git-flow implementation) and is called "support branch". There is no special naming convention yet - perhaps "version 2.1.x" might be one (as on this branch the version 2.1.x continues living. New versions 2.1.2, 2.1.3 (which haven't existed previously) might be created on this branch). From branch "version 2.1.x" only hotfix-branches should be derived (and merged back into appropriate places - at least to branch "version 2.1.x" - under certain conditions to "develop", "master" ....)

As already said, this approach is already covered by git-flow concept. For support branches see:

• A successful Git-Branching model
• Git-Flow
• What is a "Support Branch"?

-----

To be continued .... As not more than 2000chars allowed in comment

[Sebastian Penhouet]

Right. It's more likely that it's all about money. To switch to a new main Version (in your example from 2.X.X to 3.X.X) is slightly expensive due to big data migrations.
It's like you develop Windows XP, than Vista, Win7... they all come from the same code base but still there are customers on XP or Vista. Therefor you will have to develop new features for these customers quiet a long time until you stop the support for this version.

But these main versions are fundamentally different (otherwise it wouldn't be a new main version).

We decided to work with three permanent (dev, rc, r) and three temporary (feature, hotfix, bugfix) branches. On the development branch we work with the normal feature-workflow. Everytime when there is a feature freeze we merge the dev branch into the release candidate branch to make the last adjustments while working on new features for the new version. If the release candidate is final, we merge this branch into the release branch.

On a main version change we branch of all three branches (dev, rc, r).
For example (with version numbers out of your example):
Working on dev/2, rc/2 and r/2 there woud be a release commit with tag 2.0.1, 2.0.2... until start of development for 3.0.0 by 2.1.0.
Then there woud be the three new branches dev/3, rc/3 and r/3.

Most likely we will have to manage naming conventions and mergings manually.

Thanks for your help.

[Johannes Kilian]

It's like you develop Windows XP, than Vista, Win7... they all come from the same code base but still there are customers on XP or Vista. Therefor you will have to develop new features for these customers quiet a long time until you stop the support for this version.

Not quite the same - most major companies (like Microsoft) do not really care about users which use older versions. They tend to use the "classical" git-flow approach: only minor fixes on older version, no real development - until the announcement of discontinuation of the version .... ;-)

But I understand your needs as not everyone has the position to simply announce discontinuation of a certain version ...