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.
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 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.
When creating a Git alias that points to a function, sometimes Git provides the wrong tab completion by default (e.g. filename completion instead of branch name completion). This is how we can tell Git, which type of completion to use.
Conceptually, “git reset” is erasing your last change while “git revert” is adding a new change that undoes your previous change.
Sometimes when I’m working with files in Git, I find myself with a change in a file that says “No newline at end of file”. This occurs when my editor adds the missing newline at the end of the file. While you should have a newline at the end of the file, you may have a reason for not wanting to add this change. In that case, you can remove the newline from the end of the file.
I want to be able to type “git open-github-pr” and have my browser open to the GitHub URL to create a Pull Request (PR) for my current branch on the current project I’m working on. Here is how I built this.
When using git add -p and faced with a hunk that can not be split sufficiently for your purposes, you can use the e option (manually edit the current hunk). Unfortunately, after manually editing the current hunk it is common to get the message “Your edited hunk does not apply.” I’ve found there are some things I can do to avoid this failure.
We can’t do a fast-forward merge when the most recent commit on the receiving branch does not appear in the branch we are merging in. One of our options in this situation is to create a merge commit when we merge in our branch.