Git Workflows

Git workflows are nothing special. They are just a documented branching and integration strategy teams can adhere to in order to allow lots of people to work on a project together seamlessly. If the developers aren't on-board then it won't work as it's just a methodology, not some kind of special application or program.

No Flow

This flow can only really work for an individual working alone, and even then it would probably be better if they used branches for each feature. Everyone just commits directly to master without using branches. If you are lucky, there will be tagged versions that are what are deployed to production.

Github Flow

This flow is ideal for organizations that need simplicity, and roll out frequently. If you are already using Git, you are probably using a version of the Github flow. Every unit of work, whether it be a bugfix or feature, is done through a branch that is created from master. After the work has been completed in the branch, it is reviewed and tested before being merged into master and pushed out to production.

GitFlow

GitFlow is ideally suited for projects that have a scheduled release cycle. The workflow was first published and made popular by Vincent Driessen, but also covered by Atlassian.

The workflow consistes of two "main" branches that last forever. These are master and develop. The master branch is the main branch where the source code of HEAD always reflects a production-ready state (e.g. your releases), whilst the develop branch always has the latest changes that are ready for testing in a release. This is your "nightly", "unstable" line.

• There are 3 types of "supporting" branches:
  • Feature
  • Release
  • Hotfix

Feature Branch

You create a feature branch whenever you are adding a new feature, or when you are fixing a bug that can wait until the next release. If you urgently need to fix a bug that is in a release, refer to the "hotfix" branch type below. Feature branches are branched off of the develop line and merged back into develop when completed. They are not merged directly into master.

Release Branch

Release branches are created off of the develop branch and are thoroughly tested, perhaps with bugfixes merged in, before being merged into master. Feature changes should not be applied to this branch, but should be merged into develop instead for another future release. This is essentially a "feature freeze", allowing for extensive testing to take place and achieve stability. When all necessary fixes have been made, and the release is ready, merge it into master and tag it, before then also merging it into develop.

Hotfix Branch

When a serious issue is discovered in production and you urgently need a quick fix, you branch branch off of master, implement the fix, and merge directly back into master and roll out. You also merge the hotfix branch into your current release branch if one is on the go. If a release branch is not in development, then you merge it into develop instead. If you merged into release instead of develop, the code for the hotfix will make it back into develop when you merge the release branch. If you have got your flow working well with the release branch and the testing, then you really shouldn't need these hotfix branches. If you find that you are having to create a lot of hotfix branches, something is wrong with your setup.

GitFlow Summary

• Master is your rolled out production code with tagged versions.
• Only hotfix, and release branches get merged into master (ideally just release branches).
• Feature branches are merged into develop.
• Only bugfixes, not new features, are merged into release branches. If development of a new feature needs to continue, it is merged into develop, not the release branch.

GitLab Flow

I believe this is the ideal workflow for organizations that need to release frequently, rather than having scheduled releases. This is my favourite flow as it tries to keep the advantages of having a simpler flow from GitHub Flow, but have the advantages of integration lines that come with GitFlow.

Environment Branches

Unlike with the other flows where master was the line representing the code that is on the production server, this flow has a dedicated production branch that serves that purpose. Also, you will probably want a "pre-production", "staging", or "release" branch to represent your staging environment that you push to for last minute testing. This means that you should have at least 3 main lines:

• master - this is everyone's local development environment line.
• staging - this is where master is merged into for last minute tests before making it into production
• production - this is the tagged production code that staging is merged into. If you are not using staging, then you would merge here from master.

Testing

In traditional workflows, integration tests would be manually kicked off when the feature was ready to be merged into master. This would be when one would submit a pull request in Github, but don't forget that pull requests are not part of Git itself. The one issue with these tests is that they test the feature in its current state, rather than the code as a whole after it has merged into master.

One could have tests be automatically kicked off whenever a change is made to master. Unfortunately, with lots of changes continuously being integrated into the master branch, this could be an issue. Master could easily have moved on before the test results have come back from a previous merge, whereas when testing in the feature branch, the feature is not merged until the tests have passed.

I believe its best to have tests automatically kick off is in GitLab Flow's pre-production environment (staging). This line of development should change infrequently compared to master, and it's main purpose is to provide the last minute testing of all merged features as a whole before merging into production. One should still manually kick off the testing routine when in a feature branch has completed, before having it merged into master, but don't rely on that alone.

References

• Vincent Driessen - A successful Git branching model
• Gitlab Docs - Introduction to GitLab Flow
• Atlassian BitBucket - Gitflow Workflow
• Scott Chacon - GitHub Flow