Making Git Workflows Work
November 17, 2015
I remember the first time I encountered Git version control. I’d like to think I started the same way as many – you hear about this great tool and how important it is, so you get curious and meander over to GitHub. You follow a few steps, start playing with your first repository, and then proceed to unwittingly make a small mess of things with a few bad habits you carry over to the first time you use it on a team-developed project.
Now that I’ve had plenty of time to learn what not to do and settle in, it’s a little more evident as to why a proper workflow is so important to maintaining project (and personal) sanity and helping the team stay organized. Allow me to share a couple of observations. Note that this is a high-level discussion on practices and not a tutorial on the specifics of Git operation.
On the Necessity of Established Workflows
Having a lack of established process tends to lead to a bit of chaos when managing a repository. Many times, I’ve seen projects that follow a centralized workflow, where all the developers on a project are working from the same branch. It’s very workable, sure, but it requires some discipline, and it can raise a few issues:
- How much extra communication and documentation are necessary to know what work has been done at any given point?
- How can you reliably determine the state of your repository and whether it’s ready to be deployed?
- If there is a release planned and a team member is regularly pushing a future release to the working branch (again, a failure in communication), how do you promote the code to production without extra work?
Some Key Ideas to Follow
There are plenty of ways to strategize and manage your repository, but the one key idea worth repeating over and over is this: Don’t work directly in the master branch. The master branch should always reflect your current production code. Treat it as the de facto final product. Only promote code to the master branch after it’s reviewed, tested and is being promoted to production. It’s a simple behavior that can save you many pains. If all else fails – in the worst-case scenario – you know you can always fall back on this branch.
Secondly, branches are cheap, so use them. It requires little cost in disk space or performance to branch your work in Git, and merging is (in most cases) fairly simple. How you strategize your branching is up to you. Generally, it’s best to branch from your master for any feature or release. Once you’re ready to publish those updates, you can have your work reviewed, tested and then, once approved, merged into the master. You can find different strategies on how to manage your workflow (here are some examples and explanations).
What Works for Us
We’ve taken on a modified Git workflow. Our projects start off with a master and development branch. Team members are encouraged to develop all project features in feature-specific branches (based off the master). This allows development of different functionality to occur independently and be deployed in any order, as needed.
Once a set of features is ready to be tested, we create a release branch. This branch goes to quality control to be tested. Any changes can be patched in, and, once ready to go live, the commit is tagged, the release branch is merged to the master and dev, and the master branch is then deployed.
In the end, though, find what workflow works for you, and see to it that your team adheres to it. Whether a centralized workflow is sufficient, or having a larger distributed work that’s best suited to using forking and having a dedicated set of project maintainers, the most important thing is that you have a structured process to keep everyone on the same page.