I started running
$ git status
all the time and reading the output carefully.
But I could save some time after I added the following to my ~/.bashrc:
# Prepend current git branch in terminal
function parse_git_dirty {
[[ $(git status 2> /dev/null | tail -n1 | awk '{print $1}') != "nothing" ]] && echo "*"
}
function parse_git_branch {
git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e "s/* \(.*\)/(\1$(parse_git_dirty))/"
}
export PS1='\u@\h:\w\[\033[0;33m\]$(parse_git_branch)\[\033[0;m\]$ '
I found out (was told) that the equivalent of $ hg pull was actually $ git fetch. Yes, I learnt
Mercurial first.
I taught the Software Carpentry Version Control with Git lesson,
and never did $ git commit -am again.
I let go of my command-line-only dogma and started using $ git gui to add hunks to the staging area.
Now they are gone from the $ git diff output and you can find them with $ git diff --staged.
I fell in love with $ git log -G<regex>:
Look for differences whose patch text contains added/removed lines that match <regex>.
Then I would typically run git show <commit_id> to see the details.
I adopted $ git stash for test-driven development.
I ran across the well-named revert command but, admittedly, it might feel like you are adding noise
to your revision history. So I went to the dark side...
I rebased interactively, e.g.,
$ git rebase -i HEAD~3
Likewise, you may want to
$ git rebase master
when you have been working on that feature branch for so long (ship it!!) and other stuff has been
merged into master in the meantime.
Caution! Rebasing involves history rewriting (for the cleaner) so make sure you know what you are doing if you work with collaborators, if you have already pushed your work to a remote, etc.
Some thoughts and thanks go to @gdevenyi, @scjody, @charettes ! 🐤