Skip to main content

Rebase to freshen up your branch

·509 words·3 mins
Table of Contents

I’m a member of a few software teams and, very frequently, we commit code to our main branch. Common themes within my teams are not to have a develop branch or even release cycles. Instead, we release regularly.

This isn’t common practice in a big corporate but, within nimble software-focused companies, it’s fairly commonplace.

The question is, how do we do this without stepping on each other’s toes.

Git #

It comes down to git & agile. The tool we use to manage source control and a little fragment of the mentality of our project management lifecycle.

Git is simply a way to detect differences between copies. If the production copy contains A, Joe’s working on B & Sally’s working on C, Git can work out the differences and merge the copies without conflict.

The tricky bit is when work is long-lasting and contributions are committed at differing intervals.

That’s when rebase comes into play. git rebase origin/main is a way of ensuring that my work, the work branching from main, is up to date with any work that my colleagues have contributed. It’s the right thing to do and it reduces re-work in the future when conflicts arise. It ensures my work is up to date before it’s merged into the main branch. The source of truth.

Flow #

A common strategy that teams uphold is git-flow. It’s something Atlassian has very well defined and needs no further explanation.

But, I don’t think it’s perfect.

In software engineering, sometimes we tend to put automation on the processes we hold dear as mechanisms to help us be more productive. They work well, but they come with their own shortcomings.

For example, a feature branch may be a good mechanism for testing a specific feature, so each commit may trigger a quasi-deployment to demonstrate the potential of some new functionality.

The imperfect outcome is that the feature branch triggers some automated process to deploy this demonstrative feature.

This is both costly and wanting.

Work Branches #

A simple approach I’m adopting within my team is work/* branches. They’re a similar concept to feature branches, but namespaced to avoid the automated processes.

Work branches are prefixed with work/ and are explicitly excluded from automated pipelines. They’re designed to be the “Auto Save” of the source control realm.

I actively encourage my teams to work primarily within their work/* branch and only merge features to their feature/* branch when they wish for a pipeline to run.

To conclude #

I disclaim that I’ve only been practicing this within my teams for a short while, and despite the additional effort in differentiating between feature/* and work/* branches it seems to be working well.

I do recognize that block steps are also a good mechanism to reducing unnecessary deployments and unnecessary builds. These are great ways to achieve similar things, but sadly are not available in the environments I’m working within.

I’m always eager to hear feedback and possibly suggestions for new ways to work. If you have some ideas, please get in touch.

Author
Will Hackett
I’m Will, a software engineer and architect based in Melbourne, Australia. I’m currently working at Blinq.