git rebase --life

There is a line through all the chaos. Reviewing changes along the way

Be honest: Who among you has never wanted to roll back unwanted changes at some point – or wished you could use ‘git diff’ to quickly find out what has changed, even if it's just where the xyz your glasses are again?

Or, yeah, all this talk about the common thread that should run through your CV. It's easy to lose the thread on your way; it's not always the main line, maybe it runs a little crooked.

Today, I was working on some GitHub repository of mine. First, I manually uploaded some documentation I had written yesterday. I committed on a feature branch and then that GitHub action (labeler) was failing. Oh my guinness…

So I went fiddling around a bit with that GitHub actions file and committed the changes to main, asking ChatGPT for some help on how to fix the syntax due to some breaking changes which had happened between labeler v4 and v5. It turned out that the changes on main branch did not have any effect on the open pull request from the feature branch to main. 😬

Let’s skip the details, I got it all fixed and working as a charm quite soon, so here is how:

• git fetch

• git checkout feature-branch (usually git checkout fea[TAB] is enough)

• git rebase main

Why git rebase and not git merge? It depends on the situation. With git rebase, you’ll rewrite history so that it looks as if the changes on main happened first, and you created the feature branch afterwards. In my case, that was exactly what I needed, it’s pretty much like installing update #2 only after update #1 has succeeded. 😇

Let’s visualize it a bit. Herein, ❌ denotes a failing change, ✔️ a succeeded one, whereas ⭐ is that update you made on the feature branch:

(Created with Python IDLE in dark mode and The Gimp)

While I was looking out of the window, waiting for the pipeline process to finally finish and be kind enough as to get it right and succeed as the last change was made, phew, this got me thinking.

Photo by Aaron Burden on Unsplash

The branches we take …

As a creative person, I visualize and compare to examples, so don’t blame me for taking an example which may seem a bit far-fetched at first sight.

Well. If we imagine ourselves and our ways like a codebase, so we have some “legacy code” we bring or even carry around with us all the time – and we’ll have a lot of different branches, one for each role in our lives, the people we meet, the work we do, the places we go, the situations we face…

As we grow from each experience, we make some commits to one of our role-feature branches. (Sometimes they just happen as something or someone else makes a change, though. Maybe it’s through an update of a third-party service. Likewise, git blame may return null or some nickname in some cases.)

Yet, such a commit on one branch can have an unforeseen or unnoticed effect on another one later on as we go ahead with something else, seemingly undismayed, later on then sit around wondering what has happened.

Photo by Nico Brüggemann on Unsplash - Munich at night

See also my post on unnoticed help:

Such as learning LaTeX helped me writing my thesis, or such as coming to a known place with a person I know well enough made me feel safe there at night. ✨

Generally speaking, getting used to a new situation before heading first right on and feeling overwhelmed. My creativity helps me out a lot doing this…

Merge conflicts? They can happen. So sometimes, it’s good to test and rest before discarding or quickly merging a change, or to sit back, go back in history and “git rebase” a little. Or to reorganize, cherry-pick, taking small steps. ✨✨

Photo by Yosri Gam on Unsplash - Berlin Zoo subway station, uploaded 02/2025.