Programming @programming.dev fool @programming.dev 3mo ago

Julia Evans' Git cheat sheet

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)

57 comments

Damn she has a ton of these helpful tech guides on her site under "Comics".
My ideal workflow: make the smallest, fastest possible PRs so there's no tomfoolery.
- This is my take as well, and yet I have an 70+ file PR still pending a complete review... But to be fair that pr required me to change half the code base to change to a new network stackm.
I need this poster or canvas printed so I can hang it on my office wall...
- but in light mode, right? ... right?
  
  screams in ink spill
  
  Looks like the original was "light mode". The image is a colour-reversed image of the free PDF version which is on the creator's site at the bottom of the page.
  
  Direct PDF link: https://wizardzines.com/git-cheat-sheet.pdf
  
  @[email protected] @[email protected]
- 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.
  
  I use an excellent GUI that opens a terminal to run the commands you execute in it so that you can review the precise command in case you need to modify it.
  
  aesthetic. need i say more?
  
  Alternatively, the Git CLI is pretty flexible and inertia makes me stick to CLI-only lmao. Plus, PowerShell git completion is meh.
  
  (Not that GUI is bad. GitHub Desktop diffing is pretty.)
  
  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.
Missing the "oh shit need to fix this other thing but I am in the middle of a big change,,," flow. I use git stash, but I wish I could include files that haven't been added and I wish it could be tied to the branch
- That sounds like the perfect situation to use git worktree.
- I've stopped using stash and mostly just commit to my working branch. I can squah that commit away if I want later. But we squash before merge so it doesn't tend to be worth it.
  
  It's just less things to remember.
The only time I see a rebase fail is due to a conflict. Which can be aborted with git rebase --abort no need for reflogs unless you really mess things up.
- I'll admit that in 10 years using git, I don't think I've ever used reflog once.
  
  It can be nice when you successfully do a rebase (after resolving conflicts), but change your mind about the resolution and want to redo it.
  
  Doesn't come up that much, but it's been handy once or twice, for me. It's also just nice security: no matter how I edit commits, I can always go back if I need to.
- Maybe you resolved the conflict in the wrong way and want to restart after finishing the rebase.
  
  Not sure I would say that is a rebase failing - just you messing things up. Can happen with any merge. But yeah that is a place where reflog would be useful. But I dont see why it would be on the cheat sheet instead of a git rebase --abort or be rebase specific.
I went from GUI to terminal and I'll never go back. Especially with interactive add, git add -i
- I use the best of both worlds. A gui in the terminal. GitUI
- WHAT
  
  Try it out. It is a great utility.
- I recently got on git add -p, which comes in clutch sometimes. But yeah, I'm definitely about to start doing the interactive add.
  
  Also, squints at your username
- Yep, #metoo, though I started with terminal. I still use GUI but mostly only for visualizing history.
One missing point:

git stash $NAME lets you name a stash, and then you also can pop with that name to restore.

Super useful if you're doing something with plotting or presenting data and you want to try a few easy variants to see what you like most. I don't use it all the time but it's good to know.
In recent git versions (>2.23), git restore and git restore --staged are the preferred ways to discard changes in the working tree (git checkout -- .) and staged changes (git reset --) respectively.
- Huh, TIL.
  
  To be fair, git switch was also derived from the features of git checkout in >2.23, but like git restore, the manual page warns that behavior may change, and neither are in my muscle memory (lmao).
  
  I'll probably keep using checkout since it takes less kb in my head. ~~Besides, we still have to use checkout for checking out a previous commit, even if I learn the more ergonomically appropriate switch and restore.~~ No deprecation here so...
  
  edit: maybe I got that java 8 mindset
  
  edit 2: Correction -- git switch --detach checks out previous commits. Git checkout may only be there for old scripts' sake, since all of its features have been split off into those two new functions... so there's nothing really keeping me from switch.
  
  Besides, we still have to use checkout for checking out a previous commit
  
  git switch works on commits too. I don't think you have to use checkout anymore.
git has 17 million options

proof needed /s

I wonder how many it actually is.
- According to tab autocomplete...
  
  $ git zsh: do you wish to see all 141 possibilities (141 lines)?
  
  But what about the sub options?
  
  $ git clone https://github.com/git/git $ cd git/builtin # looking through source, options seem to be declared by OPT # except for if statements, OPT_END, bug checks, etc. $ grep -R OPT_ | grep --invert-match --count -E \ "OPT_END|BUG_ON_OPT|if |PARSE_OPT|;$|struct|#define" 1517
  
  Maybe 1500 or so?
  
  edit: Indeed, maybe this number is too low. git show has a huge amount of possibilities on its own, though some may be duplicates and rewords of others.
  
  $ git show -- zsh: do you wish to see all 489 possibilities (163 lines)? $ man git-show | col -b | grep -E "^ -" --count 98
  
  An attempt at naively parsing the manpages gives a larger number.
  
  $ man $(find /usr/share/man -name "git*") \ | col -b | grep -E "^ -" -c 1849
  
  Numbers all over the place. I dunno.
  
  That's less than I expected. If there's 141 commands that on average comes down to 10 per.
I use like 4 git commands in prod (make a branch, rebase, rebase interactive, push) plus git gui & gitk.
The lengths Ppl will go to in order to not use a GUI... I haven't written a git command in a terminal in years.

Learnt how it works, played around with it then used different GUI tools for it.
- My personal experience is most people who are using git with a GUI are the same people who are asking my help to git-fu their git-problems...
  
  Most GUIs only offer a subset of the git functionalities and hide what's really going on by obscuring gitshell with "their workflow".
  
  In all cases, use what you like; some people like the shell. Cheatsheets are normally only for learning purposes and usually don't stick for long, it's not an end game thing...
  
  I've been using TortoiseGit since the beginning, and it covers everything I need. Including advanced use cases. I can access almost all functionality from the log view, which is very nice.
  
  I've tried a few other GUIs, but they were never able to reach parity to that for me. As you say, most offer only a subset of functionalities. Most of the time I even found the main advantage of GUIs in general, a visual log, inferior to TortoiseGit.
  
  GitButler looks interesting for its new set of functionalities, new approaches. Unfortunately, it doesn't integrate well on Windows yet. Asking for my key password on every fetch and push is not an acceptable workflow to me.
  
  GUI users = low skill ✅
  
  Majority GUI a weak subset and of little use ✅
  
  Elitism ✅
  
  Of course, this is all couched in “use what you like”, and top it off with a general sentiment of how this post is all but useless.
  
  If someone has to ask you for your git fu help the problem isn’t GUI use it’s the incompetence and/or inability to solve it yourself. Implying a strong correlation of the two is where I take issue.
  
  My personal experience? A built in GUI saves you so much time like the one in JetBrains IntelliJ, if I need something more use case oriented that is more than the core fn (intelliJ’s does not simply include fetch/push/pull, but much more including everything in the graphic) then I click terminal tab and do what I need. Similarly the git tree provides an immediate view and context of the branches, changes, tags etc.
  
  It’s almost like filtering people into GUI and CLI boxes doesn’t really work.
- I like the terminal because:
  
  It's the same everywhere. You don't lose knowledge by switching to a company that has a different git client.
  
  You know what's going on, mostly. Most clients will assume you want to do things one way and do it that way for you, especially when it comes to fetching/pulling/merging. I'd rather go through all the steps in the terminal myself so I can assure myself that I won't be reliving various past broken merge traumas.
  
  If you like the terminal generally, you're probably also doing other stuff there anyway. So you can get used to running whatever commands to test, lint, push, etc. without switching windows or even taking your hands off the keyboard and it becomes muscle memory.

57 comments