571
Julia Evans' Git cheat sheet
(programming.dev)
Git cheat sheets are a dime-a-dozen but I think this one is awfully concise for its scope.
- Visually covers branching (WITH the commands -- rebasing the current branch can be confusing for the unfamiliar)
- Covers reflog
- Literally almost identical to how I use git (most sheets are either Too Much or Too Little)
Why not just use a gui? I don't need something hanging on my wall because it's all just easy clicking around. And when I do want to use the cli, it's very easy to bring up.
GUIs tend to only cover the common/basic usage. Which is easy to remember without a cheat sheet. When you need more advanced stuff then GUIs tend to become more of a sticking point I find. And with common workflows it is far easier to automate with the CLI then with a GUI.
Other than untracking tracked files, I see nothing in this graphic that isn't easy to do with a gui. That might even be easy to do but it is something I do in the cli. Can I get some examples?
I would also argue that the common/basic stuff is 99% of what I do with git. And for this I can't fathom why people would think the cli is better. Like logging and diffing is just so much easier when I can just scroll and click as opposed to having to do a log command, scroll, then remember the hashes, and then write the command. This is something instantly available to me in a gui.
Don't get me wrong, if the cli is better for you more power to you. We moved from p4 to git and I did this almost exclusively in the cli so I could use scripts more easily. And sometimes I watch beginners use the gui and I have to bite my tongue because I know it would be faster in the cli.
But, especially for a beginner, i strongly recommend a gui.
Interactive rebase? There's no GUI that actually does that well, if at all. And it's a massive part of my daily workflow.
The CLI is far, far more powerful and has many features that GUIs do not.
It's also scriptable. For example, I often like to see just the commits I've made that diverge from master, along with the files changed in each. This can be accomplished with
git log --oneline --stat --name-status origin/master..HEAD. What's more, since this is just a CLI command, I can very easily make a keybind in vim to execute the command and stick it's output into a split window. This lets me use git as a navigation tool as I can then very quickly jump to files that I've changed in some recent commit.This is all using a standard, uniform interface without mucking around with IDE plugin settings (if they even can do such a thing). I have many, many other examples of scripting with it, such as loading side-by-side diffs for all files in the worktree against some particular commit (defaulting to master) in vim in a tabpage-per-file, which I often use to review all of my changes before making a commit.
There are cases where instead of
origin/master..HEADyou may want to use@{upstream}..HEADinstead to compare with the upstream of your current branch. It's unfortunately quite unknown.