Here I am. Thoughtfully sitting like the French sculptor Auguste Rodin imagined “The Thinker” (Le Penseur) in the late 19th century. Thinking about how to write a blog post which should express deepest gratitude, but unable to find the right words to do so.
In order to optimize my git workflow, specifically for GitHub, I present you with some configs and tricks that I set up.
Since I like to keep my commit history linear, I personally prefer to rebase instead of merge when I pull new changes from the remote repository. This means that if I run git pull, it will not perform a fetch and merge but rather a fetch followed by a rebase, which results in my local commits being automatically included on top of the remote commits coming in. That way, I avoid having merge commits that would IMHO pollute the history.
If you want to try this out yourself, use the --rebase parameter on pull like that:
git pull --rebaseIf you feel happy with this workflow, you can set it in your global config, so you don’t need to include the --rebase option anymore:
git config --global pull.rebase trueBy default, git often initializes new repositories with master as the primary branch. However, most modern platforms (especially GitHub) have moved towards using main. Instead of renaming your branch every time you run git init, you can tell git to use main globally by default:
git config --global init.defaultBranch mainI really like to credit people who contributed in any way to my commits. What I find annoying, however, is that you have to know the GitHub email address of the user you want to Co-author. I used to go to the people’s profile, search for a recent commit they made and appending .patch to the GitHub commit URL. In the diff that you get this way, you can manually extract the email of the user. But why should I manually do this 1min work if I could spend 10h automating it?
Sorry, I just had to include those two legendary xkcds in here.
So I created a little bash script which simplifies adding Co-authors to your commits. All you need is gh and jq installed, and the little bash script below.
brew install gh jqsudo apt install gh jqSave this bash script as git-ucommit to a folder that is in your $PATH (like ~/bin or /usr/local/bin) and make it executable with chmod +x ~/bin/git-ucommit:
#!/usr/bin/env bash
# Check for dependenciesif ! command -v gh &> /dev/null || ! command -v jq &> /dev/null; then echo "Error: 'gh' (GitHub CLI) and 'jq' are required." exit 1fi
args=()usernames=()message=""
# Parse argumentswhile [[ $# -gt 0 ]]; do case "$1" in -u|--user) usernames+=("$2") shift 2 ;; -m|--message) message="$2" shift 2 ;; *) args+=("$1") shift ;; esacdone
trailer_args=()
# Resolve GitHub usernames to Co-authored-by trailersfor user in "${usernames[@]}"; do user_json=$(gh api users/"$user" 2>/dev/null) if [[ $? -ne 0 ]]; then echo "Warning: Could not find GitHub user '$user'. Skipping." continue fi
name=$(echo "$user_json" | jq -r '.name // .login') id=$(echo "$user_json" | jq -r '.id') email="$id+$user@users.noreply.github.com"
trailer_args+=(--trailer "Co-authored-by: $name <$email>")done
# Execute the commitif [[ -n "$message" ]]; then final_msg=$(echo -e "$message" | git interpret-trailers "${trailer_args[@]}") git commit "${args[@]}" -m "$final_msg"else # No -m flag? Inject trailers and open the editor git commit "${args[@]}" "${trailer_args[@]}" -efiSince the file name starts with git-, you do not even need to create a git alias, as it is smart enough to detect your executable and just allows you run:
git ucommit -m "fix: suggestions" -u trueberryless -u delucisI myself integrated this functionality into my 
nix-darwin setup. Check out my Nix module if you can profit from this setup.
🔄 Automatic Rebase on Pull
git config --global pull.rebase trueSets your global configuration to perform a rebase instead of a merge when pulling. This keeps your git history linear and avoids unnecessary merge commits.
🌱 Modern Default Branch
git config --global init.defaultBranch mainEnsures every new local repository you initialize starts with
maininstead ofmaster, aligning your local environment with GitHub’s defaults.
👥 Simplified Co-Authoring
git ucommit -m "message" -u <username>Uses a custom bash script alongside
ghandjqto automatically resolve GitHub usernames to the correct “Co-authored-by” trailers, saving you from manual email lookups.
Here are some helpful resources for optimizing your Git and GitHub workflow:
That’s it! With these tweaks, your local environment stays modern, your history stays clean, and giving credit to your collaborators becomes a breeze. Happy coding!
I like to use the git CLI. I have tried UIs like GitKraken, Fork or GitHub Desktop. I don’t like them.
The majority of commands can be remembered after a short amount of time because you use them daily. However, there are some commands you only need here and there, which makes them really difficult to memorize. Every time I need them, I haven’t used them for so long that I forget which option it was. Then I have to look them up again, feeling frustrated and uncool for not knowing Git by heart. It’s embarrassing.
So I decided to write this little post, which doesn’t help memorizing them, but I’ll always know where I can look them up quickly 😅
When contributing to open source, it is common that you want to checkout a branch of the upstream branch, that doesn’t exist in your remote fork yet. Neither does it exist in your local repository. Now when it comes to checking out a remote branch on a local repository, git switch is your friend. Just remember to fetch the upstream, so git knows the reference you want to track. However, what if the branch is not in your remote repository - your fork.
I usually have set up the original remote repository as the upstream repo locally, which can be done with:
git remote add upstream https://github.com/<org>/<repo>With this information, git can then fetch the upstream:
git fetch upstreamAnd now comes the magic: Create and checkout a branch, that until then only exists in the original remote repo with:
git checkout -b <branch> upstream/<branch>I know that it is pretty annoying that you have to specify the branch name two times, but in theory you could name the local branch differently.
Also don’t forget that this branch does not yet exist in your remote fork, but you can push it easily with:
git push -u origin <branch>If you want to rename the last commit, just use:
git commit --amendWhen you already have multiple local commits, you have to start an interactive rebase with:
git rebase -i HEAD~3Here, 3 is the number of commits you want to adapt. If your commit is back 10 commits, you need to put a 10 there instead.
Git will open your favourite editor with some text like:
pick 64e085f Commit Message 1pick e5f607a Commit Message 2pick a9b0c1d Commit Message 3You can now edit this text like a normal file and replace all the pick keywords where you want to change the commit message with reword. After you save and close the file, git will repeatedly open text files with the old commit message, which you can freely edit to your likings. After you adapted everything you wanted and close the last file, the rebase is finished and you can check your corrections with:
git log --onelineInteractive rebasing is incredibly useful, as other options like squash, break or even exec are available. Just keep in mind that it makes more sense to do this on a branch where only you work to avoid team friction.
When a PR is merged, the branch is usually deleted after it is safely merged into the default branch. But the branch still exists locally. If you want to delete all the local branches, which got deleted in your remote repository, you can run this command in most shells (use wsl on Windows):
git fetch -p && git branch -vv | awk '/: gone] / {print $1}' | grep -v '^\*$' | xargs -I{} git branch -d "{}"🛰️ Track Upstream Branch
git fetch upstream && git checkout -b <branch> upstream/<branch>Fetches the latest references from the original repository and creates a local branch that tracks the upstream version in one logical flow.
🔄 Rename Older Commits
git rebase -i HEAD~nUse this to rewrite history. In the interactive editor, change
picktorewordfor any of the lastncommits you want to modify.
🧹 Prune Local Branches
git fetch -p && git branch -vv | awk '/: gone] / {print $1}' | grep -v '^\*$' | xargs -I{} git branch -d "{}"A pipeline that identifies local branches whose remote counterparts have been deleted (“gone”) and attempts to delete them safely.
Here are some helpful resources for learning git and other situations you often find yourself in:
That’s it for now, more useful uncommon git commands might be added in the future!
Have fun.
You could stop reading right now. Contributing to open-source projects is not about creating a reputation. It doesn’t bring you any fame. You can’t force yourself to create, write or refactor code just for the sake of helping out. Although it might seem that many projects can only be sustainably maintained through more contributors, the additional effort for maintainers to review pull requests that got created due to the need for recognition actually slows down progress as those maintainers have to invest their time into analysing your code. And don’t even get me started with vibe-coded issues or code changes.
I am not claiming to understand open source and its contributions by any means. And I think everyone has their own opinion on that, which is totally fair because it differs depending on the communities and languages that exist. So in this post, I am gonna share my current personal opinion, which changes over time. It changes in every programmer’s lifetime with the experiences you make, socially and in terms of knowledge.
Contributions are not just coding. And open source is not just about contributions. You can give value by triaging and responding to issues, commenting on discussions, continuously improving workflows, updating dependencies, supporting others with the knowledge you have already learned, or really any non-code contribution as long as you interact with the people in a friendly way. Software is shaped by the people that build it. And you can help build this community around it.
Programming in this sense is the challenge of self-discovery. You have to find what you love. You gotta do what interests you. Your motivation is the only substance that allows you to perform at your best. But you may not know what motivates you from the beginning. Sometimes discipline beats motivation. Some people discover their passion through the discipline of showing up. Not everyone knows what they love from the start.
Start simple. Notice a docs typo, share personal feedback in a discussion, report an issue you stumbled upon in your own projects or just get in touch with the people of the community to see if this is the place you would like to be. Nobody is perfect, and neither are most first contributions - even from people who later become maintainers. And you will get a warm welcome even if you make mistakes because that’s human. Just avoid over-relying on AI to do the work for you. Learning the codebase yourself is part of the journey. Not every PR will be accepted, and that’s okay. Sometimes the timing isn’t right, or the approach doesn’t fit the project’s vision.
If open-source software has helped you in your journey, contributing back helps sustain the ecosystem we all benefit from. When you are working at a company, it makes sense to suggest sponsoring the projects you depend on. Because if maintainers can focus full time on keeping the software up-to-date via financial support, they will not consider changing the FOSS license to a commercial one. If everyone thought this way, everyone would be better off.
One thing I noticed during my contributions is that maintainers generally appreciate contributions which actually affected you. This might sound obvious for some of you, but it is a crucial detail my past self also forgot to care about. Fixing issues you didn’t encounter yourself can help you learn to recognize common design patterns. They are also useful if you want to get started with a project, on your way to finding your passion with discipline. However, by doing so you give yourself the huge disadvantage of not knowing the motivation behind it.
And I think that this detail sets apart “good” from “bad” developers. The former ones do not try to be the best, they just mostly do the stuff they enjoy. Open-source projects are created in people’s spare time for a reason. I couldn’t bear writing software in my free time which doesn’t affect me. But I somehow manage to sit down after a full work day, still having the strong will to submit yet another pull request to my favourite open-source project. Because I have fun doing so!
Feel free to share this post with the people you think could benefit from it.
Since Spotify recently updated their prices across all available premium plans, I decided to test out one competitive platform: YouTube Music from Google.
While many reviews and comparisons focus on the major differences, like price, algorithms, music recommendations, playlist creations and other promoted features by those platforms (including garbage AI features), this post focuses on unnecessary comparisons between little things most people don’t care about.
This guide shows how you can append additional content like credits, ads or additional information below to list of headings in your right 
Starlight sidebar.
This guide shows how you can customize the first heading in the right sidebar (table of contents) of every Starlight page globally and individually.
This article demonstrates how code snippets can be created in Visual Studio Code that can significantly boost your productivity when regularly working with Astro’s content collections.
Have you ever wanted to simplify sidebar generation in your Starlight project? Have you tried autogenerating the entire sidebar only to find it doesn’t let you customise the structure to your needs?
This post demonstrates two Starlight features that make fully autogenerated sidebars flexible and reduce maintenance.
It has been more than two and a half years since the release of ChatGPT. The 30th November, 2022 marked the beginning of a new era. The start of AI. Nowadays, many professions and people in private lives, especially in the information technology sector, use it on a daily basis. And we do not even know where we are on the Gartner hype cycle or if AI will improve following Kurzweil’s “Law of Accelerating Returns”.
The trend is still rising, but at the same time I have noticed a slight but steady degradation of knowledge on a human basis because people delegate more and more creative work to AI. As a result, I have decided to write a little blog post, where I can share my thoughts, trying to discourage the overuse of Artificial Intelligence which would ruin our cognitive capabilities. And although I know that very little people read this, it does not stop me from trying. Otherwise, I might have missed my opportunity in helping humanities future.
Today, I want to talk about a small VS Code extension that I vibe-coded in a single day to make working with Terraform easier. I will first explain what Terraform is, and then jump right into the functionality and reasons behind this extension. Feel free to skip the first section if you are already familiar with Terraform.
Yes, this title is a small nod to the excellent Netflix series “Arcane”, but that’s not what this post is about.
Today, I want to share some thoughts about earworms, a term that originated in German (“Ohrwurm”) and was later adopted into English as a literal translation. The meaning behind this rather abstract term is catchy tunes—sticky music, as Wikipedia calls it. This phenomenon often occurs unpredictably, especially when our thoughts drift away from the present moment.
Discover how a tiny Rehype plugin can give your GitHub links a big visual upgrade. With just a few lines of code, we’ll turn regular profile links into elegant badges with avatars, inspired by Antfu’s site and powered by Astro + Starlight.
I have been working in OSS on 
GitHub for over a year now and although I thought I found everything I want to contribute to, I recently discovered 
Peli’s personal project action-continuous-translation and I am very happy that I started doing regular contributions there and being part of the little community now.
Talk a little bit about how one can become better (not master by any means, nobody is perfect) in writing a blog post. These are just my thoughts after two awesome guys from the Astro Community (
Jacob and 
Lou) decided to write blogs about how hard and easy it is to write blog posts.
Please read their posts first as this is the follow-up on both of them:
After that you have successfully completed this awesome trilogy of blog posts about blog posts.
Learn how to create a horizontal progress indicator for your Starlight site.
Combine two Starlight Sidebar Topics plugins to show a list of topics on desktop and a dropdown menu in the mobile sidebar.
In this post, I’ll show you the evolution of Starlight plugins with a case study of the Starlight Sidebar Topics plugin. Be prepared to find out some impressive facts about people and code around Starlight.
In this blog post, we’ll take a look at how small changes can make a big difference when it comes to whitespaces in your Starlight sidebar.
This year, I turned 20 - and instead of simply lighting candles and inflating balloons, I wanted to celebrate in a more creative and personal way. The idea? Hide the number 20 in as many surprising, clever, and hidden forms as possible throughout a decorated living room - then capture it all in a single photo. Whether through mathematical puzzles or visual Easter eggs, the room transformed into a joyful riddle full of playful detail.
Every great project starts with a realization of a problem. My GitHub profile README was cluttered, filled with too much information, too many badges, and an overwhelming amount of content that lacked style and structure. It had hackathon achievements, GitHub contribution graphs, various technical badges, and much more, making it visually unappealing and difficult to navigate. Initially, I thought this was an effective way to present myself, but over time, it became clear that the information was overwhelming rather than informative. I wanted something new, a more refined and visually appealing approach to presenting my profile, and the idea of implementing a bento grid came to mind. The goal was to create a layout that was not only functional but also aesthetically impressive and structured.
Creating a standout GitHub profile README isn’t just about adding a few badges — it’s about pushing technical boundaries. In this deep dive, I explore low-level SVG manipulation, HTML-to-SVG conversion, inline animations, and full automation with GitHub Actions to build what I believe is one of the most technically advanced GitHub READMEs. From a dynamic Bento Grid that updates every 5 minutes to embedding live SVGs without external requests, this project transformed my profile into a living, self-updating showcase of my work. Want to know how I did it? Let’s break it down. 🚀
This is the story of how I came up with the wonderful but meaningless username “trueberryless”.
Starlight Cooler Credit is a customizable plugin that gives stylish, multilingual credit links to Starlight, Astro, and the Starlight Blog—turning a small idea into a global collaboration.
Today we’ll take a look at how to set up a GitHub repository which will be deployed to a k3s cluster via Argo CD. In summary, the article will include Workflow files, Dockerfile, manifests (deployment) and 
Docker Hub repositories. Please check out our Argo CD blog because this will be a continuation of the other post.
Continuing to improve our k3s cluster and especially the CI/CD workflow, we now take a look at the GitOps tool called 
Argo CD, and how we can integrate it into our cluster. Our tech stack for deployment uses these services: k3s, Helm, Cilium & after this tutorial Argo CD as well
True Tracker is a minimalist time-tracking app built with Next.js that keeps all data in your browser — no accounts, no database, just complete privacy and simplicity.
This blog posts describes the process of setting up a 
Kubernetes cluster with 
k3s and 
Cilium. We use 
Helm as the package manager and 
Cloudflare as the certificate issuer. We used the tips and tricks from Vegard S. Hagen from his article. Essentially, this blog explains, how all the trueberryless.org websites are deployed (not any more).
For our diploma thesis with Siemens AG, we built a service-oriented solution to detect power grid anomalies — featuring a Kafka pipeline, PostgreSQL, GraphQL API, and an Angular dashboard with tables and an interactive graph for real-time visualisation.
Mutanuq is a fast, Markdown-powered website I built to organize school content, streamline studying, and create a reliable resource for classmates and myself.
