Git: Deleting old local branches

Just looking at old local branches. They tend to proliferate, especially if you have a release cadence.

To list the local branches (the default), or list the branches according to a pattern, see the two examples directly below.

git branch
git branch --list "V2022*"

Small explanation of the output of the command:

• existing branches are listed
• the current branch will be highlighted in green and marked with an asterisk
• any branches checked out in linked worktrees will be highlighted in cyan and marked with a plus sign

I'm usually only interested in local branches, but "-r" shows remote-tracking branches and "-a" shows both remote and local branches, if you're interested.

Removing branches

git branch -D `git branch --list "V2022*"`

Bear in mind that branches that are used by a worktree cannot be deleted. Remove the worktree first.

Actually, I really like that behaviour.

Checking old branches

Apparently you can sort the list of branches based on last comitterdate.

git branch --sort=-committerdate # DESC

In the example above, you'll see branches that have been committed to recently at the top.

Finding a commit

This is nice, you can find which branches contain a certain commit quickly.

git branch --list --contains 089aafb331a08d19ed805fff6fea3846776980a0

Unfortunately, we're currently using git as a local repo, and svn remote, so there's a disconnect between commit hashes.

References

Git - git branch documentation

https://git-scm.com/docs/git-branch

StackOverflow - Can you delete multiple branches in one command with Git?

https://stackoverflow.com/questions/3670355/can-you-delete-multiple-branches-in-one-command-with-git

"if it hurts, do it more often."

I recently came across the phrase "if it hurts, do it more often."¹ on the website of Martin Fowler.

Now, this might not be appropriate to, for example, slamming your hand into a car door, but it does have its uses, for example, in sports.

Personally, I think it is one of the defining characteristics of humans versus animals, that humans can suffer through a bad cause (pain/hardship/uncomfortableness) if they know the effect later is appropriately good. In other words, humans have the ability to reason about causality³, usually with a perception of time.

Unfortunately, sometimes the animal instincts prove stronger.

Continuous Integration

The soundbite in the title comes straight out of the realm of Continuous Integration².

I came across the sentence, as I was wrestling with a problem at work. We have several branches, which are specific to certain of our customers. An often heard complaint nowadays is that these are so called 'Long-lived branches'. Now, the more I consider it, the more I think long-lived branches are a pretty bad idea.

The complaint I hear most often is that some of our software developers are spending more time merging changes to the different branches and keeping them in sync and retesting, than actually developing new software.

I just thought I'd put down some references (see [4] and [5]) on how to get rid of long-lived branches, and keep everything in the main branch. I don't feel sanguine about convincing management, though.

References

[1] Martin Fowler - Frequency Reduces Difficulty

http://martinfowler.com/bliki/FrequencyReducesDifficulty.html

[2] Wikipedia - Continuous Integration

http://en.wikipedia.org/wiki/Continuous_integration

[3] Causality

http://en.wikipedia.org/wiki/Causality

Lean into the pain

http://www.aaronsw.com/weblog/dalio

[4] Martin Fowler - Feature Branch

http://martinfowler.com/bliki/FeatureBranch.html

[5] Martin Fowler - Branch by Abstraction

http://martinfowler.com/bliki/BranchByAbstraction.html