This only works in small teams and doesn’t scale to larger teams due to becoming complete chaos while losing the ability to craft good commits. In truth, this doesn’t work for projects with only a single engineer either because you need to have a feature branch running against CI to confirm your changes are stable before rebasing onto the main branch. Otherwise, your Git history becomes murky and hard to read as you constantly make more commits to fix mistakes.

The above is akin to how Git was designed where feature branches are meant to be short lived, constantly deleted, and main is always production-ready. The major downside is, by default, this workflow tends to be merge/squash merge heavy which leads to a non-linear and hard to read/maintain Git history.

You should avoid using this workflow due to the following reasons:

This workflow is most common in Open Source where you don’t have access to the main repository so must work off the fork. In general, this workflow is fairly clean because, once your work is complete, you can delete the fork to reduce your maintenance burden. Sadly, I see way too many engineers with forked repositories that haven’t been touched in years that should have been deleted long ago.

Ultimately, if actively working on a forked repository, you eventually get elevated to committer status in the main repository which means you can abandon this workflow in favor of whatever workflow the main repository is using.

The problem with most of the above workflows is they:

Can we do better? Yes we can! Let’s talk about how we can approach this problem using the Rebased Branch Workflow with a strong focus on capturing the what, why, how, and who of our work.

At a high level, here are the primary benefits of leveraging this workflow:

A typical workflow consists of the following steps:

With this workflow, you can still have multiple environments. At minimum — and a given — you’ll need a Production environment. Typically, you’ll have both a Stage and Production environment. Optionally, you’ll want a Review environment which is automatically spun for each code review and automatically torn down after the code review.

In either case, the workflow might look like this:

Having too many environments is like having too many branches which increases cost, adds additional maintenance, and slows team productivity. Keep your environments to a minimum and use only what you need.

Git Tags (a.k.a. milestones) are lightweight aliases to a Git commit SHA. Even better, they can have a subject and body, much like a commit message. Most importantly, tags allow us to differentiate between various milestones and their associated deployments.

While you can create an arbitrary label for a tag, please don’t. Every tag should use Strict Semantic Versioning. Briefly, this means your tag must consist of the following:

Here are a few examples, with comments, to detail what each version is:

A tag needs to be created with every deploy. Even better, this can be automated with Milestoner using Git Trailers. All you need to do is one of the following trailers when creating commit messages:

You can use Git Lint to enforce consistency and ensure all trailers are properly formatted. Then, when it’s time to deploy, Milestoner will automatically calculate the correct version, since last tag, based on your commit trailers.

 — Alexander Pope

Try as we might, mistakes will happen. Using this workflow vastly reduces them. That said, in situations in which a production issue crops up, we can quickly cherry-pick a patch onto main for deployment.

In general, the cherry picked SHA(s) would be atomic and sourced from a feature branch with strict adherence on the SHA(s) being code reviewed and green in CI before being deployed. Example:

Ideally, you wouldn’t cherry pick at all but simply create a feature branch off of your currently deployed tag. For example, consider the following (assuming you’ve already deployed 0.5.0 and need to patch it):

💡 The use of git merge --ff-only 0.5.1 is, essentially, the same manual step as used within the GitHub UI when pressing the Rebase button once your code review is approved. The --ff-only option ensures no merge bubble is created. Highly recommend setting this as your default in your global Git Configuration.

You’ll recall, when discussing common deployment workflows earlier, that some workflows relied on feature flags you could toggle behavior on/off without deploying new changes. There is nothing stopping you from using feature flags in this workflow either.

Keep in mind that feature flags incur a maintenance cost. This means you must remain diligent in deleting them as soon as you are done using them or you’ll end up maintaining code no longer used.

In addition to the above — and hinted at throughout this article — the following Ruby gems are great for augmenting this workflow within your own team(s):