KINTO Tech Blog

From Git-flow to GitHub-flow

R Wen
R Wen
Cover Image for 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.


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.


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.


Git Flow 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.


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 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.


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.


  1. ↩︎


関連記事 | Related Posts

We are hiring!


プラットフォーム開発部 について共通サービス開発GWebサービスやモバイルアプリの開発において、必要となる共通機能=会員プラットフォームや決済プラットフォームの開発を手がけるグループです。KINTOの名前が付くサービスやTFS関連のサービスをひとつのアカウントで利用できるよう、様々な共通機能を構築することを目的としています。


新車サブスク開発グループについてTOYOTAのクルマのサブスクリプションサービスである『 KINTO ONE 』のWebサイトの開発、運用をしています。​業務内容トヨタグループの金融、モビリティサービスの内製開発組織である同社にて、自社サービスである、TOYOTAのクルマのサブスクリプションサービス『KINTO ONE』のWebサイトの開発、運用を行っていただきます。