Typically a Git commit has exactly one parent, however a Git merge commit has two parents. The problem this creates with Git revert, is it is unclear which commit we want to revert to.
A Pull Request (PR) should always be up to date with the branch into which it is being merged. Another way of saying this is you should be able to merge your PR as a fast-forward merge (even if you decide not to do a fast-forward merge). In this post we’ll look at how a safe looking PR that is out of date can be catastrophic to merge.
When deleting a large directory from the command line, it can take a frustratingly long time for the task to complete. This is a trick I use to speed things up.
Recently, I was documenting the steps to reproduce a certain bug and the bug required the presence of an autosave (along with the “There is an autosave of this post that is more recent than the version below.” message). Rather than wait for an autosave to occur naturally, I wanted to speed things up and manually trigger one. This is the command I use to do that.
I’ve been using Git for a number of years. When I was a Git beginner, I followed some prescribed steps and things worked – most of the time. This seems to be a pretty common experience for people starting out with Git. The magical part is when I started to understand Git, when I went from beginner to intermediate. These are some blog posts and videos that would have helped me with that transition.
I was recently working on a project that loaded WordPress from a sub-directory. The result of which is if I cloned the project into the “public” directory, the WordPress files and directories were one level deeper (in “public/wordpress”).
When working on projects, I often want to strictly control the version of WordPress that is running. However sometimes one of the other administrators on the site sees the “WordPress 5.9 is available! Please update now.” message and clicks it, thereby prematurely updating to a newer version of WordPress core. This notice can be disabled.
I recently had a conversation about “git reset –hard” vs “git checkout -f”, and it turns out they do the same thing. This is one of the tricky things about Git, there are often multiple ways to do the same thing.