Advanced Git commands every senior software developer needs to know

optimizedbyotto.com

2 pointsottoke4 comments

As aliases:

alias g-log="git log --graph --format='format:%C(yellow)%h%C(reset) %s %C(magenta)%cr%C(reset)%C(auto)%d%C(reset)'" alias g-history='gitk --all &' alias g-checkout='git checkout $(git branch --sort=-committerdate --no-merged | fzf)' alias g-commit='git citool &' alias g-amend='git citool --amend &' alias g-rebase='git rebase --interactive --autosquash' alias g-pull='git pull --verbose --rebase' alias g-pushf='git push --verbose --force-with-lease' alias g-status='git status --ignored' alias g-clean='git clean -fdx && git reset --hard && git submodule foreach --recursive git clean -fdx && git submodule foreach --recursive git reset --hard'

I'd put git blame and git bisect above all of these.

You need bisect only as a last resort. Effective use of git blame, git log -p -S <keyword> etc has always been enough for me. Also, the projects I work with take 10+ minutes to compile even when cached, so doing tens of builds to bisect is much slower than just hunting for strings in git commits and code.

I've had git bisect work perfectly to show me that a commit that I would swear up and down couldn't cause the problem was what was causing the problem. In those kinds of situation git blame and git log are a bit useless since you can be looking right at the commit in question -- even looking at the diff in question -- and fail to actually 'see' it and go chasing down other rabbit holes that seem 'obviously' much more likely to be the cause. And this was typically after some customer updated for the first time in several years and so there was several years of changes to sift through to find the regression.

Reply on news.ycombinator.com