gitbranching-and-merginggit-flowbranching-strategy

Git branching model strategy

We are trying to follow the gitflow branching model, but with a twist.

We have have four servers environments where the product can be deployed to, each server serves a purpose : development, internal testing, external testing, and production.

We are trying to make the merging / conflicts resolution as easy as possible, so we created two extra branches which is not part of the gitflow model.

Normal gitflow branches

But also these two branches which is not standard and might need to change...

Then process is then as follow:

Are we messing up the whole gitflow model?

Here is our brancing process: enter image description here

Solution

  • To answer your question, no you're not messing up the gitflow model - more extending it to meet your needs.

    By coupling environments to a given branch, you're giving yourself much more flexibility when it comes to building releases. i.e. lets say you have two non-dependent features (Feature 1 and 2) in progress, both of which have been merged into your 'TestServer' branch. If Feature 1 fails testing, Feature 2 can still be progressed further without Feature 1 - this is because your merge into 'TestServer' is a one-way merge - nothing comes out, no history. Instead, your Feature 2 branch is merged into 'develop' and eventually 'master'.

    We're in the process of adopting/developing a similar strategy to yourself. The key requirement for us is to accommodate the unavoidable cherry-picking of features. Note that our solution, although rather complex, has been designed for an enterprise application, serving as a platform for multiple services owned by multiple business-owners and utilise multiple in-house frameworks..

    Environments

    These environments are grouped into two categories, 'in-test'(QA, Stage and UAT) and 'production' (BETA and LIVE).

    Branches

    Feature prioritisation can change often, from testing issues through to regulatory restrictions/requests. To accomodate this, multiple branches are created to represent the environment/categories as follows:

    We also utilise a HotFix branch from Master as required, and prepare production releases in a 'Pre-Production' branch (correcting missed version increments etc - minor stuff).

    A diagram of our Branches in use: A diagram of our Branches in use:

    Branching and Merging / WorkFlow

    1. We always branch new Features from Release-Candidate as this branch always contains the 'Committed for production' features. Nothing leapfrogs once the commitment for production has been made.

    2. Once a feature is ready for testing, it's merged (one-way) into 'Stage'. This triggers a CI build and deploys to QA.

    3. If the QA server looks stable, the developer triggers an automatic deployment to Stage.

    4. If changes are required then make them in feature and repeat. If OK for business testing, then merge from Feature to UAT. This deploys to UAT.

    5. If feature fails business testing, then make changes in feature and repeat. If feature is delayed then take no action. If feature is OK and signed-off, then merge to Release Candidate.

    6. Once collection (1 or more) of features are in Release-Candidate, trigger production deployment by merging from Release-Candidate to Master (via Pre-Production).

    7. Deployment failed, then HotFix. If OK, deploy to Live.

    Our workflow, using TFS, looks like this:

    Our workflow, using TFS, looks like this:

    Release workflow

    And finally, each deployment to an environment/category would look like this:

    Flow of deployment