If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
Here’s what’s new in our January 2023 Release Notes:
* Tables Columns Sorting Improved
* Reconcile Commits Count Between KPI Card and the Table
* Efficiency Tab Improvements and Efficiency KPI Cards Align
In having recently covered How to Reduce the Size of Your Git Repository and When to Refactor Your Code, it’s logical to talk about which Git Branching Strategy you should use and when. GitFlow stands as one of the first strategies to be defined and, as such, it became a sort of an industry standard. A lot can change in ten years, but – that doesn’t mean changes are necessarily better or worse. It could be they’re just different. Either way, having more than one version control branching strategy to choose from is a good thing.
When working with Git, a Git branching strategy (or version control branching strategy) is the model used so that your codebase evolves in a logical, consistent, and (a mostly) “easy to understand” way. The model provides the rules for how, when, and why branches are created and named. There are different branching strategies that allow for work on like-concepts to be organized and developed in parallel.
DevOps focuses on efficiency – making things easier and faster without compromising quality. Where branching strategy is concerned, DevOps wants to know how pull and merge requests are handled, the amount of overhead involved in managing the branches. The ease of reading the project’s history could also weigh in. Mike Kaufman, a Microsoft Regional Director, MVP and VP of Consulting Services for CGI discusses branching strategies for DevOps in detail. He summarizes,
“It’s very important to find a branching strategy that fits the way the team works. If branching is not done right, it introduces big burdens and slows the team down. It also can impact the quality of your product… The best guidance is to start small and add complexity only if you need it.”
There are many version control strategies, as Scott Shipp points out in War of the Git Flows. Now, I’ve got no problem donning a flak vest and kevlar helmet and getting down for a low crawl, but… war? That’s a tad bit extreme. Messin’ with my CCCCD Ice Cream – that’d be war! But this… this is merely like a TV episode of Survivor, but with no cash prize.
| Strategy | Overview |
|---|---|
| GitFlow | Created by Vincent Driessen, GitFlow works with two main branches – master and develop – over the lifetime of the project. It also uses three supporting branches: feature-*, hotfix-*, and release-*. It’s the most complex model. |
| GitHub Flow | A simpler strategy promoted by Scott Chacon of GitHub mandates keeping a continuously deployable main branch. A feature branch is created to work on any feature or bug fix. Each feature branch must be finished and fully tested before being merged with the main branch. |
| Trunk-Based Development | Very similar to GitHub Flow except that Trunk-Based Development suggests deployment after production code is merged to the main branch to minimize chances for regression. |
| GitLab Flow | Created by GitLab, this strategy is like an extension of GitHub Flow with master and feature branches. However, it adds environment and release branches to better support SaaS and mobile projects. |
| OneFlow | Formulated by Adam Ruka, OneFlow proposes to be a simplification of GitFlow with the use of rebase options some consider controversial. |
Already, we can extinguish the torch of one of our brave contestants. Trunk-Based Development didn’t get with the Flow. It’s very, very similar to GitHub Flow. The difference between GitHub Flow and Trunk-Based Development can be seen comparing the two images below:
For a more visual demonstration of workflows, this video showcases GitFlow and GitHub Flow.
Let’s move on to a comparison of the basic strengths and weaknesses of the remaining 4 Git branching strategy options. Each is designed for different scenarios. What’s best for a startup isn’t always going to work well for a large enterprise.
| GitFlow | GitHub Flow | GitLab Flow | OneFlow | |
|---|---|---|---|---|
| Types of Projects | Enterprise | Startups | All | Enterprise |
| Branch Overhead | Heavy | Light | Variable | Light |
| Work Process Complexity | Complex | Simple | Simple | Medium |
| Merge Difficulty | Hard | Easy | Easy | Easy |
| Delivery Support | Releases | Continuous | Both | Releases |
| History | Convoluted | Clean | Clean | Variable |
| Feedback | Slow | Fast | Fast | Fast |
It’s not so complex that you can’t understand the process, but it’s not easy on the eye, either.
GitFlow, though ubiquitous, has some limitations and issues that constrain its effectiveness. It’s perhaps the first clearly defined version control strategy to have been created. Functionally, it doesn’t work well for Continuous Delivery/Deploy or Multi-Environment projects. It works well for open-source and established/enterprise software projects so you can keep close control over any changes. It’s a useful strategy for large teams having many junior developers with close oversight by senior developers.
However, this can also lead to process bottlenecks and slower feedback. So, a moment of silence for GitFlow and its ten years of fame. GitFlow… your torch is extinguished.
Down to three – GitHub, GitLab, and OneFlow. The best version control branching strategy depends on the type of project and the size, structure, experience of your team, as noted by Mike Kaufmann.
However, when first starting out, it’s best to stay simple and keep it simple until the project reaches a point where additional complexity is needed. For this reason, the GitHub Flow (or Trunk-Based Development) is the best strategy for the early stages of most projects. It’s ideal for solo developers and small teams working on software projects requiring only a single version of a release to be maintained. In such cases, they may be able to stay with the GitHub Flow for the life of their project.
Projects requiring Continuous Releases or supporting more than one environment should eventually transition to the GitLab Flow. Continuous Releases apply to SaaS type projects. Multiple environments often come into play with mobile apps – which must be approved by an app store before being made publicly available. In such cases, you don’t have control over the exact timing of production releases.
OneFlow has the same limitations as Git Flow except it maintains a single long-lived branch and makes for a project history that is far cleaner and easier to read. Some developers like its use of squashing and rebasing, and others don’t. OneFlow provides more flexibility for handling team decisions inferring extra care when overseeing many junior developers. That OneFlow can do everything that GitFlow does, despite the controversies over its many options, makes it worthy of consideration.
The GitLab Flow strategy, in our assessment, is the most versatile of the three survivors, and a natural evolution for when your project gets too complex to continue with GitHub Flow. But, each team and project is different and has its own requirements.
So, this isn’t to say that other branching strategies aren’t good or useful, though GitFlow itself is probably the case of last resort and for when you have a high ratio of junior to senior developers. Even then, it’s not optimal for being slow with the potential for many bottlenecks.
If you would like more tips on Git Workflow Strategies and other ways to improve your team’s productivity, the following articles should be interesting for you:
Article updated: May 11, 2022
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
Here’s what’s new in our January 2023 Release Notes:
* Tables Columns Sorting Improved
* Reconcile Commits Count Between KPI Card and the Table
* Efficiency Tab Improvements and Efficiency KPI Cards Align
Here’s what’s new in our December 2022 Release Notes:
* Developing Improvements for On-Prem Data Processing;
* Improving Jira Data Connection;
* Aligning Metrics throughout the Application.
