nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

Johannes Kilian_pi36cl

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...

All comments

Johannes Kilian_pi36cl

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_pi36cl

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_pi36cl

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:

-----

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

git-flow