There are many possible workflows with GIT – while many can be implemented using SVN, some of the more advanced workflows are more difficult or even impossible within SVN.
There are a few well-known, well-published examples of advanced GIT workflows, each with their own benefits and costs.
GITFLOW (http://nvie.com/posts/a-successful-git-branching-model/) is a popular workflow that gives more developer independence, while maintaining stable, releasable master branch. One downfall of this approach is only one release can be “in development” at any one time.
I developed the Release-Manager-Feature-Pull model to resolve some common development issues discovered in an existing project. While it shares some features of GITFLOW, it varies in a way that makes each branch purpose more clear and any stage of development very easy to pinpoint.
In this model, as a developer begins to work on a feature, a branch is created specifically for that development. The developer works on this branch, and concurrantly test resources are developing tests specific to the new feature – preferrably automated tests, but scripted manual tests can also suffice. The intent is that when the development effort for the feature is complete, the test suite is also complete. This test suite can, and SHOULD be run against a deployment of the feature branch before declaring the feature release-ready.
Concurrant to the branching and development of feature branches, branches can be initiated for a release. A release branch is a simple branch from the current stable trunk. No development is completed on the Release branch, and the release branch is owned by a “Release Manager”. Release mangaer is not a position or title, it is a responsibility, and can be assigned to a developer, qa resource, or manager.
The Release Manager “builds” a release by accepting new features into the release branch. To incorporate a feature to the release, a Pull request is made from the feature branch to the release. This allows one final code review to occur if desired before actually incorporating the code into the release. The Release Manager will accept the pull request, and the feature AND ITS TESTS are incorporated to the release.
This will include as many or as few features as the release manager deems fit, and sufficiently tested to release to production. The final release is tested through all of the tests of the individual features, and may have additional integration tests created as well.
Once the feature set of the release is finalized, and testing is complete, the release wiill be tagged, and produciton deployment can occur from that tag.
When the release tag is deployed to production AND NOT BEFORE the release branch is merged to master. At this point, all branches that fed to the release should be considered dead and receive no new changes.
It is possible to work on multiple concurrant releases – in this case, when a release makes it to produciton and is merged to trunk, there needs to be an immediate merge of the current trunk changes to all oustanding release branches.
Some releases may have all testing completed, and be signed off for production, but never deployed. This could happen when non-project issues prevent deploymnets, etc. When this happens, the relase branch should NOT be merged to master, as it is not in production, and master should always represent the latest production release. Instead, the following release branch should pull the non-deployed release and incorporate in the next release.
It is important to note a few special features of this workflow.
Releases can be sequential, or paralelle
Features do not have to be incorporated into releases in the order they are developed – the release manager will determine this based on priority and available testing capability.
Guaranteed stable release timing is very easy to achieve with this workflow, as adjusting to the release date simply requires the release mangager to adjust what is accepted into a specific release.
Early test development is encouraged. The earlier a defect is detected, the easier / less costly it is to fix.
Reduces the effect of bottle necks on other development resources.
(See following diagrams)
