Going with the (Git) flow
This blog post outline the pros and cons of the Git workflows propagated by well known software engineering platforms.
Each of those platforms recommend their own Git workflow or Git branching philosophy.
Remember: Branching is the core concept of Git. But you can use this feature in different ways.
This blog post shall give you a short overview about the different Workflows and their pros and cons.
Different Workflows
Gitflow
Vincent Driessens post was one of the earliest description of a workflow model. He describes the idea and the actions required very well.
The model suggest to use two „main“ branches: master and develop. The master branch is the Git default branch. And in this workflow the branch is used to tag releases.
The develop branch is where feature and release development takes place. This leads to additional effort for merging. You need to merge „hot fixes“ and „release branches“ in to two other branches: master and develop.
Furthermore most git tools consider the master branch as the default branch and are configured accordingly.
GitHub
The GitHub Flow is a lightweight, simple workflow. This provides many degrees of freedom how to work with it. On the other hand this requires to clearly decide in a collaborative project from which branch you want to release.
Forking is branching on project level, kind of and popular on GitHub. But this is a different story.
GitLab
GitLab propagates two workflow models: Environment and Release branches.
The Environment workflow is useful for DevOps as well as other features (e.g. Docker Container Registry) of GitLab.
The Release workflow is based on the upstream first policy to avoid version fragmentation. But you have to spend time on cherry-pinking bug-fixing patches into different releases.
Bitbucket (Atlassian)
Bitbucket supports various workflows from above. Those are the Centralized, the Feature Branch, the Gitflow and the Fork Workflow.
VSTS
The Microsoft recommendation is also to use branches. But for long running branches they recommend using feature flags/toggles and don’t recommend Tags for releases. Using feature flags require disciplined work and following known best practices to keep your project tidy.
Not using tags increase the effort required to keep your release branches updates with latest features and bugfixes. Using tags for releases in a specific branch would be less effort.
Others
Git documentation describes some workflow models as well. One of those models (Dictator and Lieutenants Workflow) is well established in the Linux Kernel development.
Conclusion
Don’t go with the Git Flow!
A Git workflow is a powerful tool to arrange the way you work in your project. Think, chose and adapt the „best“ workflow for the needs of your project and organisation.
Be aware if your workflow becomes a mess, mostly your project and/or organisation is a mess as well.
Choosing a workflow for your needs is the beginning of your journey with Git. Best practices (Rebase, Merge/Pull Requests, ..) for your journey will follow…
This post appeared first on my personal blog.
