When I do a git rebase and I get a conflict, I can use git log to see all the commits rebased thus far. However, I often get confused about what the current (incomplete) commit is that caused the conflict. It would be super helpful if I could see the commit message of the current commit. This command allows you to view the current (incomplete) commit during a rebase.
When working with Git on the command line, I spend a lot of time switching back and forth between two branches. Even with Git tab completion, it is a lot of typing. However Git has a shortcut for the previous branch, a single dash (-).
I was working on one Git branch and I wanted a file from another branch. Using git checkout, we can do this.
I’ve written about using “git push –force-with-lease” instead of git push –force” because “force-with-lease” will only force push changes if your local copy is aware of all of the commits on the remote branch but how is git “aware” of the commits.
Never use git push –force. Seriously, don’t use it. You should always use –force-with-lease instead. We’ll look at the problem with –force and how –force-with-lease addresses the issue.
Both HEAD^ and HEAD~ can be used in Git to refer to previous commits but in different ways.
By default Vim is the editor used when writing a Git commit message. While I love Vim, it does work very differently than most other editors. A good option for those who are not comfortable with Vim, is to use a different editor. This is how to setup Git to use a different editor.
The interactive rebase feature of Git is one of my favorites. I love being able to squash multiple commits into one commit or re-order my commits for clarity. My one complaint is the Git interactive rebase commit order is wrong (at least for the way my brain works).
When using Git, sometimes (often) I find myself forgetting to delete local branches after merging them. This command deletes this branches (and I’ve included a Git alias to make it easy to use in the future).
I see lots of people get themselves into trouble when using git cherry-pick. By removing the commit from the source branch after cherry-picking, I’ve been able to avoid many of these problems.