Issue title: Apply Git workflow: GitFlow
 Issue body: 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](http://nvie.com/posts/a-successful-git-branching-model/).
- [GitHub Flow](http://scottchacon.com/2011/08/31/github-flow.html) as answer to [What is a good Git workflow?](https://help.github.com/articles/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. mgay@example.org/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 mgay@example.org

I also requested for comments on soci-users in [Apply Git branching model](https://sourceforge.net/mailarchive/message.php?msg_id=30107525) thread.

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

 Comments: 
 Comment 0: Conclusion post sent to soci-users under [RFC Apply Git branching model](https://sourceforge.net/mailarchive/message.php?msg_id=30107525) thread:

On 3 March 2013 01:40, Mateusz Loskot mgay@example.org 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](https://github.com/nvie/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`

 Comment 1: [Using GitFlow With GitHub](http://datasift.github.com/gitflow/GitFlowForGitHub.html) is a really good introduction to GitFlow for GitHub users with [The Poster](http://datasift.github.com/gitflow/GitFlowWorkflowNoFork.png) where all the basics are displayed.

If you use SourceTree, check [Smart branching with SourceTree and Git-flow](http://blog.sourcetreeapp.com/2012/08/01/smart-branching-with-sourcetree-and-git-flow/)

 Comment 2: 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](https://github.com/SOCI/soci/wiki/Flow), so contributors will be displayed with name of GitFlow and at least know they should branch off from **develop**.

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

{'source': 'GithubIssues', 'repo_name_with_owner': 'SOCI/soci', 'issue_id': 8416705, 'repo_stars': 1168.0}