Here is an exhaustive (~99.5%) list of the git commands I use:

  git init
  git clone
  git clone --recursive
  git remote add
  git checkout
  git branch
  git merge --no-ff
  git add
  git add -p
  git rm
  git reset
  git commit [-a] [-m]
  git commit -p
  git commit --amend
  git submodule add
  git push
  git push -u
  git pull
  git log
  git show
  git status
  git update-index --assume-unchanged (aliased to ignore)
  git update-index --no-assume-unchanged (aliased to unignore)

The 1 in 200 is probably a git rebase -i.

If we're doing something other than git I'll be happy with those. Specifically add/commit -p are important to me.

I’d encourage anyone using Git take a closer look into “git rebase -i” (interactive rebasing) combined with “git add -i” (interactive staging).

While working, I’m freely taking advantage of Git’s capabilities on a personal level, producing many sometimes messy WIP (work in progress) commits, trying things on short lived branches, reverting changes, and so forth, but afterwards I am able to copy edit the results to produce a sequence of finalized commits that form a coherent narrative that reads like how I would describe my work to a colleague or manager.

To me, interactive rebasing has been the difference between “my team uses Git” and “I first and foremost use Git for myself, and then also use it to share the results with my team”.

I nearly always "git rebase -i" before opening a PR, and even after. Squash, re-order, reword FTW. Recently I started using "edit" to split previously squashed PRs back out.

I like presenting and merging tidy changes.

"git stash" is something I used to use all the time, roughly daily.

"git blame" is also very useful.

"git bisect" is remarkably useful once a month or so. It does a binary search to find the commit that broke whatever thing you've recently discovered is broken.

Bisect might be one of git’s killer features: you rarely reach for it, but when you do it saves your ass and saves the day.

Recently my coworker asked for help tracking a regression after spending hours finding the culprit, I bisected it in a couple minutes and his mind exploded :-)

I run git rebase -i a lot more often because I like to reword a bunch of commits to make the commit messages clearer just before pushing.

And git reflog is indispensable for fixing things.

And I'm surprised you didn't mention git diff. I do that all the time to compare things, like having a single diff of all commits between the origin diff base and current HEAD. Also useful for summarizing changes of entire feature branches.

Git is like C++. People learn and use a different subset of it and everyone claims their own chosen subset is powerful enough and entirely sufficient for everyone.

Darn I actually missed git diff. I haven't been using a bash history so I don't have something check against. I'm confident now it's complete tho.

Rebase -i is a lot to fun, I ought to practice it more. Haven't had to use reflog yet, but I'll be expecting it now thanks~

me]$ cat .bash_history | grep git | awk '{print $1,$2}' | sort | uniq -c | sort -n

      1 git clone
      2 git cherry-pick
     10 git reset
     17 git merge
     23 git fetch
     34 git checkout
     37 git rebase
     66 git diff
     75 git pull
     79 git log
     87 git branch
    126 git commit
    135 git add
    141 git push
    201 git status
    205 git grep

    122 git bug
    124 git branch
    169 git show
    247 git reset
    274 git rebase
    308 git fetch
    310 git fixup
    576 git commit
    633 git push
    692 git pull
    889 git stash
    949 git diff
   1122 git add
   1681 git checkout

Where `fixup` is https://github.com/hashbang/dotfiles/blob/master/git/.local/...

I always recommend to people to not use 'git pull' as it's probably not what you really want.

What do I want? It sure seems to do exactly what I need in the case where I'm on my local `master` and it's exactly the state of `origin/master` but a day or two behind.

What is it you're doing on your local master? It's only going to lead to a mess if you're developing on master locally and trying to do merges from upstream.

Absolutely no development. I use it as my starting point for feature branches, as well as subsequent rebases and merges on them. And I use it to build and run the current master.

I don't use git; years ago I chose mercurial and have stuck with it. And I'm by no means a power user. But I've always wondered why git "won".

git before github existed was a pain to use. I honestly just continued to use SVN because the tool support (like automatic renaming in IntelliJ when refactoring a class) just worked, and there was concern about exactly how to back up our source code.

After github, things became much easier and it is likely the main reason people use git over mercurial.

Of course, now I work at a place that uses Mercurial, because Git can't handle the size of our repo (an order of magnitude, at least, bigger than the Linux kernel)...

git even before github was a game changer for distributed development, kernel being the most prominent example. It did not require random people to have connectivity or authorization on some central SVN server, and yet they could clone and sync their trees and create branches to their heart's content.

But mercurial was also in play then and seemed better (which is why I chose it) or at least on par. Somehow git got more traction and is now the default.