During development I’m constantly applying small fixes to my code. It could be anything from improving some comments, simplifying some conditional statements, or doing a small refactoring like extracting some lines into a simple method. Most of the time these small fixes end up either in small commits that dilute the git history or in commits that have a completely different focus and thus dilute the change set of those commits. But there is a better way to incorporate those kind of changes into your codebase.
The topic of planning in software development is a contentious one. Some argue that software is inherently too intricate to plan accurately, prompting the question of whether planning is even worthwhile. It’s not uncommon to see Agile methodologies being used as a shield to avoid planning. For instance, teams claim, “We focus only on the[…]
Welcome to my second post in the series of lesser-known git commands. If you have missed last week’s post about git worktree you can find it here. This week we will look at git filter-branch. Hopefully, you will not need it that often but if you do git filter-branch is extremely powerful in rewriting your[…]
I thought I would start a blog post series about some lesser-known git features. So here we go! With no further ado let’s kick things off with git worktree. Normally if you clone a repository you are switching branches in your working directory. But let’s imagine you don’t want to or are not able to[…]
Most parts of the libraries I maintain are written by me. So why is it, that I try to write good comments and good commit messages, even if I might be the only one ever reading them again.
Over the last couple of month, my Twitter feed recurrently showed me tweets like “If you feel safe releasing on Mondays, why don’t you on Fridays” or “If you can’t release on a Friday you can’t release at all”. I didn’t like the tone of this tweets, and they felt wrong.
A while ago I had a look at our git commit messages and found myself in some kind of a whatthecommit mess. I remember clearly that we agreed on doing commit messages the git, or as I call it, the Beams way, don’t worry, I’ll explain what that means a bit later. But agreeing obviously wasn’t enough, to actually follow the rules.
If I would have a mantra, wich I don’t, it would be something like „never stop learning“. I try to keep an open mind and take inspiration from new things. But I do this development thingy for quite a while now and time builds opinions and more and more time toughens those opinions.
A while ago I gave a short talk at our office in Frankfurt. I talked about 10 git tips that come in handy when doing version control with git.