git logo

Our simple git branching model


At Hark, we have 3 full-time developers who maintain about 30 client sites on a regular basis. Each developer might potentially need to make edits to any site, depending on availability. Code changes run the gamut from emergency bug fixes & security updates, routine change requests, or longer-term site enhancement projects.

That’s a lot of code changes across a lot of projects, especially for a small team like ours.

Due to this, we need a way to manage each site’s codebase that allows for larger features to be staged and approved by the client, while also allowing for smaller deploys to the production site in the meantime.

We heard about git flow and liked the idea of having a master branch that by definition was production-ready, and keeping individual change requests contained to their own branches. This would avoid the faux pas of deploying code to the live site and accidentally deploying another developer’s changes that weren’t quite ready yet.

However, the concept of branching off develop and then merging up the chain in defined releases didn’t really gel with the fact that we’re building CMS-based websites for clients with many ad-hoc requests, not a software product where we can dictate how and when things are deployed.

Here’s what we came up with:

  • The master branch is always production-ready. The develop branch is always staging-site ready. If there’s code on either of those branches, by it’s okay to be deployed to the corresponding site – no need to even ask.
  • When working on a code change, create a feature branch off master and work locally. You can prefix it with “feature/” or “hotfix/” depending on the type of request, if you want.
  • If this is a change that needs to go live ASAP, merge it directly into master and deploy it to the production site. Then afterwards merge it back into develop to keep the staging site in sync with production.
  • If it’s a larger change or something that needs to be tested/approved by the client before it can go live, only merge it into develop. Then deploy the develop branch to the staging site. If the client comes back with any edits after reviewing the staging site, make those edits on your feature branch and continue merging into develop. Once it’s approved by the client, merge the feature branch into master and deploy to the production site.
  • If two or more developers need to collaborate on a larger change request, that feature branch should be pushed to the remote git repository (we use GitLab) for each dev to push to. It should still be merged into develop for deploying to the staging site though.

That’s it! No tags. No release branches. No pull requests (usually). Real simple.


Explore more posts in the Hark blog –>

Want to learn more about how Hark can help?