The Perfect Git Workflow

I have concocted the world’s most perfect Git workflow.

Here it is.

Spoiler, it’s actually not perfect, but it works for me.

In Git, there’s the concept of a master branch. Master is merely the first branch Git creates. Git might as well called it “Pippy Pee Pee Diarrheastein Poopypants Esquire.” But Git didn’t do that and so it’s called “master.”

Master, Master, where’s the dreams that I’ve been after? Master, Master, you promised only lies

Master is just a branch like any other branch. You can choose to never use master. I use it. I treat master as the main trunk of the Git tree.

When making a release of code to production, I use master to create the release.

When making codebase changes, I branch master and perform my changes in that branch.

At my current job, the process to roll out to production requires a business owner review the changes.

To do the review, I create a review branch which corresponds in name to what the next release will be called. Therefore, if the next release is 1.2.1, I create a branch of master called review-1.2.1 and merge whichever changes need to be reviewed into it.

Once the review is done, the changes or branches which pass review are merged to master and a release is created for production.

To include more changes in the release to production, the process will start over with a new review branch.

This workflow allows for an unlimited number of dev branches to be created. The review branches gives business owners the opportunity to approve code changes, this keeps stuff out of master that will not go in the next release.

It’s not the most perfect workflow, but it does work for me.

In my ideal world, each change is done in a branch, reviewed quickly and pushed to production as they’re reviewed. But my current process doesn’t allow that, I have to create releases that contain multiple change sets. I think it’s more error prone, but there’s nothing I can do about it.

Share Button