From Git-flow to GitHub-flow

Hello! 👋

This is Ruoyang Wen from Global Group, KINTO Technologies. I work as a full-stack engineer in Global KINTO App team. You can read more about the Global group here.

Objective

As a startup company, there are a lot compromises within our first generation product. For the greater benefits, apart from the service we provide, workflow is also where we need to improve.

This article shares why and how we changed our workflow from Git-flow to GitHub-flow.

Attempt

As part of the Toyota group companies, we implement the principle of improvement (or kaizen in Japanese) in our daily work. With customer feedback and analytical data, there are numerous amount of improvements that we can do to better serve our customers. Through automation, the process of kaizen can be sped up rapidly.

Committing source code is a daily job for engineers, it’s not just about handing over our daily work but also testing the code in our server environment. We introduced Continuous Integration and Continuous Deployment (CI/CD) practice into the team to help us reduce repetitive work.

CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. ^[1]

We were following Git-flow to manage our source code and development progress. Soon after CI/CD was implemented we found that our work process did not get any faster.

Reasoning

git flow diagram

It was a mess to use or manage the CI/CD scripts. We have so many different branches, when merging branches from one category to another different scripts are needed: feature-to-develop, develop-to-release, release-to-main, hotfix-to-main, main-to-develop, develop-to-feature, etc… Conflicts would show up everywhere! And they cannot be solved via automation scripts. The automation increased our daily workload, why?!

After some research we found that: Git-flow, by definition, is a manual/time delayed integration workflow. OK, we need a new workflow then.

Reattempt

Among several workflows we found during previous research, we decided to give GitHub-flow a try as we store our source code on GitHub.

github flow diagram

This time we only have two type of branches: the main and the 'change-of-anything', and we block any commits to main directly, the only way to update main is to do a Pull Request towards main. As a result, there is only one CI/CD script required and any conflicts can be discovered and resolved during Pull Request.

New Issue

We have simplified our branching strategy; we have only one script to do CI/CD; we have Pull Request to help managing conflicts. All happy? Yes, but no.

Let’s check the pros. We have handed over the repetitive work to automation scripts, so everyone can do more productive work. The release and deploy process is handled by scripts, so any change we made locally can be deployed to server within 2 minutes.

However, there are the cons. We lost feature/version control of our system. As features are no longer stored in individual branches but in main directly after Pull Request, we cannot decide for next version which features may be on-hold and which may be released. Also, the main branch just kept updating with latest source codes, version number can ramp up hundreds in a single day.

Next Step

Fortunately we are not alone. There are people who already faced these issues, and we can follow their journey and see their solutions.

Feature toggle can be used to enable/disable any feature at any time. It can be stored in parameters, so no new release/deploy needed; even better than Git-flow which is to release different versions with different combinations of features.

Version number only ramps once we deploy a specific commit to the production environment. For the rest of the environments, we use the commit hash as the version number. This helps us to locate any bug or defect to that commit instantly.

Summary

Undoubtedly there is no perfect solution to solve all problems. GitHub flow has its flaws as well, my team and I are still working together to kaizen not just our products but also the way we work.

Personally, Git-flow is like a web portal: it categorizes everything with defined rules; if no one makes any mistake it will work just fine. On the other hand, GitHub-flow is like a search engine: we tag the version number to the commit we release/deploy to the production environment, with other environments having the commit hash as version numbers; so if there is any issue, those versions can be easily found through search.

References

• トヨタ生産方式
• What is CI/CD?
• What is Continuous Integration?
• Git flow for agile teams is a no no
• Please stop recommending Git Flow!
• Git Flow vs GitHub Flow
• GitHub flow - GitHub Docs
• Continuous Integration Contradicts Features Branches!
• How to Achieve Continuous Deployment with Feature Flags

脚注

1. https://www.redhat.com/en/topics/devops/what-is-ci-cd#overview ↩︎