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:
That’s it! No tags. No release branches. No pull requests (usually). Real simple.
Want to learn more about how Hark can help?
Posted in Technology, Web Development