Back in August 2019, I wrote git and git-flow, a guide. I intended it to be used internally by GumGum to familiarize new hires with the workflow we use.

It covers a wide range of topics for people new to git and git-flow; however, it doesn’t cover everything I wanted it to cover. It was easy to say, I’ll do it later, but life happens, and almost two years later, the first part gets modest monthly views and reads while I fear that someone else will notice I never got to writing the second part. …

As with most tech companies nowadays, at GumGum, we use Git for source control, specifically, the git-flow branching model. It gives us flexibility to work on features and bug fixes independently, without affecting production, staging, or someone else’s code, and while also setting conventions that speed up opening and reviewing Pull Requests.

This post does not intend to explain git’s concepts in depth. Instead, it will be a step-by-step guide on how my team relies on git and git-flow, with examples from things we do everyday and things that may come up every now and then to surprise you.

Who is this post for?


We are big fans of React at GumGum. In fact, most of our apps have been built with it and almost all of them use Redux as well.

However, it wasn’t always like this. One of our first applications was built with Flux and while it works perfectly fine, there is some degree of context switching fatigue, especially for engineers working on newer Redux apps. Also, being unfamiliar with Flux can allow for some bugs when the store is read on component mount but not updated again afterwards. Since Redux passes the state as props, we can be sure that…


I like some stuff

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store