Git

A Guide to using git pull --rebase effectively Using git pull --rebase as your default merge strategy offers several benefits, particularly in maintaining a clean and linear commit history, which can simplify collaboration and code review. However, users may occasionally encounter the error “Cannot rebase onto multiple branches”. This article explains why this happens and provides a solution to make git pull --rebase work seamlessly. Benefits of git pull --rebase Linear History: Rebasing applies your local commits on top of the upstream changes, creating a straight line of commits without unnecessary merge commits....

I love blogging with Hugo  external link and I have two blogs already that use it. The good thing about static sites is that you have all the data in the files. You can optimize them locally, batch process, amend, etc. Powerful templating engine allows to quickly pre fill documents in the format I like. I have some steps in the Makefile for things like image optimization, but I often don’t remember to run them 😃...

I use Git a lot, even writing this article i will commit text few times. There’s a set of aliases I rely on daily and they’re first I add in new place. Some Git commands are unnecessarily verbose. You can make your life much easier with bash-completions, but if you write it tens of times per day, it’s anyway a lot of typing… and I’m a lazy man 😄 Simple status/log checks git s s = status --short --branch --untracked-files Shows a short, branch-focused status with untracked files....

I don’t know how it is in your company, but in mine it’s considered a good practice to add ticket numbers to commit messages. It allows to easily determine why something was changed, etc. Makes sense, but this also means, that I should be adding this ticket to every message… And this doesn’t make sense for me. I will accidentally avoid it from time to time or make a lot of typos....