I’m a big fan of Git and I’ve worked with lost of developers in growing their Git skills. Often developers learning Git, start by learning how to write a “good” commit message. While writing “good” commit messages is an important skill, in my opinion it is the wrong place to start.
These are the rules I follow when writing Git commit messages. I’ve found these serve me well and are compatible with most projects I work on (if a project has a specific set of rules for writing Git commit messages, those would override any rules I’ve outlined here).
When performing a Git rebase, I often find myself in the situation where I have one or more merge conflicts. This is how I resolve these merge conflicts.
Recently on a project I wanted to migrate WordPress users with a certain role to a different role. This is the command I used.
When working with Git and you run “git pull” sometimes you get the error message, “There is no tracking information for the current branch.” You can fix this by running a command to set your local branch to track the origin branch of the same name.
One of the things that made me much better at Git was making my current branch (and whether or not I have any changed files) always visible. By default zsh includes everything you need to do this, you just need to configure it.
By default “git branch” will list all of your local branches with an asterisk in front of the current branch. We can remove the asterisk and list only the branch names by adding the “format” parameter.
I recently setup a new MacBook as my primary machine and I made these notes in the hope they will streamline the process for me in the future.
As part of my work I spend a lot of time in Jira. Now that I’m using Alfred as part of my daily routine, I’ve created an Alfred workflow to help me.
Every developer I know struggles with impostor syndrome. The problem with this fact is, if people I admire for their many skills have impostor syndrome then clearly I am an impostor since I’m not as good as they are.