Apply Git workflow: GitFlow

[mloskot]

This task discusses Git workflow that is aimed to be applied before releasing next SOCI , either bugfix release for 3.1.0, or new features release SOCI 4.0.0.

At the moment, SOCI development history is flat and there is no easy way to apply bug fixes to existing releases, thus no easy way to issue bug fix releases.

There are two popular Git workflows:

• git-flow proposed as A successful Git branching model.
• GitHub Flow as answer to What is a good Git workflow?

In GitHub Flow article, Scott Chacon says:

For teams that have to do formal releases on a longer term interval (a few weeks to a few
months between releases), and be able to do hot-fixes and maintenance branches and
other things that arise from shipping so infrequently, git-flow makes sense and I would
highly advocate it’s use.

For teams that have set up a culture of shipping, who push to production every day, who are constantly
testing and deploying, I would advocate picking something simpler like GitHub Flow.

I think, git-flow is the right choice for SOCI. It is simple and based on use of two branches only: master and develop, where in fact, on daily basis, only develop branch is used.

---

What I look for is a dead simple, clear, safe,well structured Git workflow with the following features:

1. Easy for continuous development and integration of features, patches, pull request
2. Easy to mark every major release (tags)
3. Easy to mark every bugfix release (tags)
4. Easy to maintain what has been released (branches)
   • apply bug fixes
   • issue bugfix release
5. Repository at github.com/SOCI/soci
   • is the only upstream repository with SOCI source code
   • is a complete history of SOCI (commits, and all milestones and snapshots too)
   • has clear structure of public only stuff, no private branches, no feature brunches
   • must provide access to every release of SOCI, as there were no downloads at SF.net

I also requested for comments on soci-users in Apply Git branching model thread.

Please, feel encouraged to post your comments on this topic.

[mloskot]

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

On 3 March 2013 01:40, Mateusz Loskot mateusz@loskot.net 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.