Apply Git workflow: GitFlow

[soci]

Apply Git workflow: GitFlow

[mloskot]

Conclusion post sent to soci-users under RFC Apply Git branching model thread:

On 3 March 2013 01:40, Mateusz Loskot [email protected] wrote:

It's not a problem to rename the git-flow's branches

• 'master' is the current development line, corresponds to git-flow's 'develop'
• 'release' is the current stable (deployable, production-ready)
  branch, corresponds to git-flow's 'master'

After reading Pro Git book and Git manual, followed by kernel Git workflow
I stand corrected about the principle behind the master branch:
master tracks the commits that should go into the next release;
In most scenarios based on releases, it is production-read deployable state of work.

The actual development happens in topic branches.
The develop (or 'next') are integration branches.

Things can potentially get broken in the integration branch, but mustn't in the master branch.

I aim to follow this well-known, well-tested and common approach: the GitFlow

If we decide to rename the original git-flow branches, then it will
look this way:

• master - dark blue line, current development work
• release - light blue line, reserved for release tags only
• release/v.X.Y.Z - orange line, release integration branch

This naming is not possible as once we add 'release' branch,
Git won't allow to add the one with subtoken, release/X.Y.Z

[mloskot]

Using GitFlow With GitHub is a really good introduction to GitFlow for GitHub users with The Poster where all the basics are displayed.

If you use SourceTree, check Smart branching with SourceTree and Git-flow

[mloskot]

I've just made first step and applied the GitFlow scheme to the repository:

• master branch - represents the latest released codebase
• created develop branch - main development branch (i.e. branch from here if you want to work on SOCI 4.0.0 features)
• published release/3.2.0 - branched from develop for preparation for 3.2.0 release, once released will be merged back to both, master and develop.

Here are the three basic rules:

• If you want to work on new features or more elaborate issues that won't be included in SOCI 3.2.0, branch off of develop (if you will use GitFlow localy, new branch will happen in features/new1)
• If you want to test the upcoming release and apply necessary fixes, work in release/3.2.0.
• Do not branch off of master to start new work.

If you like it, use gitflow software as it really makes the process simple.
If you don't like it, you can still use plain git and expect no problems.
Just remember: branch develop for new, keep master stable.

There is lots of good readings about GitFlow as it has become de facto a standard for software rolling cycles of traditional releases. However, I will wrap up basic info on the Flow, so contributors will be displayed with name of GitFlow and at least know they should branch off from develop.

[mloskot]

I consider it's happened. Should any new issues be discussed, either reopen this or open new issue or post to the mailing lists.