I’d like developers, even seasoned ones, to learn Git’s internals on a basic level. You don’t have to be able to rewrite the whole thing from scratch, but it’s better to see how commits, branches, tags, and the like are interconnected, so it’s easier to back off when you mess up something. Also, people should finally learn that Git and GitHub/GitLab are not the same: there is no such thing as Pull Request in Git lingo. </rant>
Still, if i have to choose some Git commands, it’s stash (especially stash branch) and rebase (especially interactive rebasing).
Stash is an obvious choice for me. When i have changes not ready to be committed, i stash it away. When popping it back and it has too many merge conflicts, instead of resolving them there i like to move it to a separate branch instead. This can help a lot, especially if you stash a change you don’t want to commit later.
Rebase, i think, will meet some resistance. I know there is an ongoing religious war between rebasers and mergers, and i’m not going to promote any of them. However, rebase has a lot of use cases even if you are a merge believer.
Found a typo in a commit you haven’t pushed/merged yet? Do an interactive rebase, reword that commit, and you are done.
Found two commits that should be in one? Do an interactive rebase, and use squash or fixup to combine them.
Found a typo in the contents of a commit? Interactive rebase to the rescue, just use the edit keyword, amend that commit and you are done.
The only confusing thing during rebase conflicts is that “our state” is actually “their state” (so when you see “deleted by us”, it actually means it was deleted in the commits you are rebasing onto).