Git cheat sheet [pdf]

A couple of hidden gems:<p>git diff --staged (shows the diff between the last commit and what you&#x27;ve got staged, great when what you&#x27;re staging is finicky, lets you double check that you have precisely the files&#x2F;hunks you intended)<p>git log &lt;file&gt; (git log, but for just commits where &lt;file&gt; was touched; saves pilfering through all of git log, especially useful when the file only gets modified infrequently)<p>Random tip: when using git add --patch, try the &#x27;e&#x27; option if you need more nuance than the hunks git provides (it contains instructions for how to ex&#x2F;include individual lines, so you don&#x27;t have to remember how to do it).

One of faves isn&#x27;t listed.<p><pre><code> git log -LstartLine,endLine:fileName </code></pre> It&#x27;s like an extended git blame, showing how the specified lines evolved over time, and by who. Tracks the change as the line numbers evolve, and even as the file is moved.<p>Answers the questions of &quot;who did this, when, and why?&quot; &#x2F; &quot;How long has it been like that?&quot;, etc.

&quot;There are only two hard things in Computer Science: cache invalidation and <i>naming things</i>.&quot; - Phil Karlton [0]<p>Based on the above statement, I find it extremely weird to see such git command named &quot;<i>blame</i>&quot;, then I realized I&#x27;m not the only one:<p>What does &#x27;git blame&#x27; do? [1].<p>Blame someone else for your bad code [2].<p>Git blame should be called git credit [3].<p>Does Git Blame sound too negative? [4].<p>______________________________<p>0. <a href="https:&#x2F;&#x2F;skeptics.stackexchange.com&#x2F;questions&#x2F;19836&#x2F;has-phil-karlton-ever-said-there-are-only-two-hard-things-in-computer-science" rel="nofollow">https:&#x2F;&#x2F;skeptics.stackexchange.com&#x2F;questions&#x2F;19836&#x2F;has-phil-...</a><p>1. <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;31203001&#x2F;what-does-git-blame-do" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;31203001&#x2F;what-does-git-b...</a><p>2. <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27963868">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27963868</a><p>3. <a href="https:&#x2F;&#x2F;dev.to&#x2F;damcosset&#x2F;git-blame-should-be-called-git-credit-27h5" rel="nofollow">https:&#x2F;&#x2F;dev.to&#x2F;damcosset&#x2F;git-blame-should-be-called-git-cred...</a><p>4. <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;ProgrammerHumor&#x2F;comments&#x2F;r5lzyo&#x2F;does_git_blame_sound_too_negative_just_look_up&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;ProgrammerHumor&#x2F;comments&#x2F;r5lzyo&#x2F;doe...</a>

I liked the way I learned git. I started with sourcetree, a third party git gui. Super simple to use and understand. Then I moved to git gui, this step could be skipped. Then I got tired of pulling up my UIs and learned the terminal commands. Highly suggest this for anyone new, but just my (n=1) experience.

Is there a historical reason why git is needlessly complex?<p>Seeing this cheat sheet really brings it to life.

I didn&#x27;t know about `git add -p`. Really useful!<p><pre><code> -p, --patch Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.</code></pre>

Love this. I would add:<p><pre><code> git commit —-fixup $COMMIT_ID </code></pre> combined with<p><pre><code> git rebase -i upstream&#x2F;master —autosquash </code></pre> These have become staples of my recent workflow. Julia’s example uses HEAD^^^^^ to rebase the previous 5 commits. I have been doing this as HEAD~5, until recently I realized you can just rebase all commits up to the upstream HEAD.

&gt;squash the last 5 commits into one: `git rebase -i HEAD^^^^^^`<p>Shouldn&#x27;t this be: `git rebase -i HEAD~5` ?<p>Assuming you only want to rebase linear history.<p><a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;2221658&#x2F;whats-the-difference-between-head-and-head-in-git" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;2221658&#x2F;whats-the-differ...</a>

The biggest eye opener for me is understanding that all those commits are &quot;still in there&quot;. Tags and branches merely point to a commit and the commit that branch used to apply to isn&#x27;t gone.<p>Many (probably fair to say &quot;nearly all&quot;?) commands will be non destructive in that you can easily refer to older incarnations of your branch.<p>I&#x27;d seen &quot;git reflog&quot; but mostly used it to remind me of &quot;that branch I worked on a while ago&quot;.<p>I gained a semi-healthy fear of operations that could land me in the middle of a conflict resolution that I wasn&#x27;t interested in handling right now (often because the conflict occurred because I was referring to the wrong commit&#x2F;branch).<p>I haven&#x27;t completely cured that fear but at least I feel pretty comfortable recovering any old work among rebases, etc.

I&#x27;ll say it aloud: People need to drop git and look at JJ<p><a href="https:&#x2F;&#x2F;martinvonz.github.io&#x2F;jj&#x2F;v0.17.1&#x2F;" rel="nofollow">https:&#x2F;&#x2F;martinvonz.github.io&#x2F;jj&#x2F;v0.17.1&#x2F;</a><p>I think even Linus thinks git has a shitty UI. JJ has an amazing workflow.

I always find it interesting how knowledge makes it hard to comprehend the difficulties other people have. I used to barely understand git, but after a couple of years working at a company that relies on a rebase workflow, I&#x27;d like to think I largely understand how it works. Its nice to recognise pretty much every operation on this cheatsheet.<p>Is it common that developers still have issues with git after using it professionally for a couple of years? Admittedly, I still have trouble remembering the commands to do what I want (hello, rebase --onto A B C), though :P.

One thing missing that I use <i>all the time</i>, &quot;git cherry&quot;. Without arguments it will show you what commits in your local branch are not in your remote tracking branch. Use &quot;git cherry &lt;ref&gt;&quot; to list the commits in the current branch that are not in the given ref.<p>Most simple use is to know what you are about to push. Second use case is getting a commit list for release notes when using deployment&#x2F;promotion branches.<p>Super useful, I thought everyone used it but maybe some don&#x27;t know!

Cool cheat sheet, especially because it covers common use cases. But practically everything covered here I was able to learn independently with Magit. It&#x27;s also much easier to press one or two keys in the magit-status buffer than to open a terminal and manually type git commands, so I pretty much never use the git CLI directly, not even for a clone.

This is great, especially the little diagrams which help illustrate rebasing vs merging, one of the tricker parts of the git learning curve.<p>Having said that I think it could more clearly state the author&#x27;s typical preferred practice for updating a branch and integrating it with main when you&#x27;re done. There&#x27;s a few techniques listed for diverged branches, but then fast-forward merge is in its own box and it&#x27;s not super clear how you might use working-branch rebasing with it to eliminate divergences in the first place (even though it&#x27;s hinted at under &quot;pull changes&quot;).<p>I wonder if it would be clearer to say something like &quot;combining branches: rebase your branch and do a (FF) merge, optionally with squashing,&quot; or however they like to do it.

Maybe my favorite option is missing here.<p>`git commit -v`<p>This will put the diff of the commit into your commit message as comments. Makes it easy to remember what you&#x27;re doing&#x2F;committing without having to jump back to the terminal&#x2F;someplace else to look at the diff.

If you aren&#x27;t already, you can also try Magit. It really helps one master and interact with Git.

Every cheat sheet like this highlights the surprisingly high learning curve of the git cli. It&#x27;s an interface that really ships it&#x27;s underlying data model rather than optimizing for common workflows. This isn&#x27;t necessarily a bad thing, but I often feel like the target audience of git is the power user, leaving me uncertain anytime I need to perform an intermediate level action.<p>Lately I&#x27;ve been enjoying Graphite as a tool to interface with git. Commands are based around atomic actions I want to perform, despite often triggering multiple git commands under the hood. This has reduced my overall mental overhead, and removed many footguns.

I have a funny little habit that probably stems from a certain degree of paranoia when working on a decent-sized change. I like to keep a local patch of it, as follows: &quot;git diff &gt; works.patch&quot;<p>Later on, you can apply it if necessary with &quot;git apply works.patch&quot;.

Read once here, the best cheat sheet is one you create yourself. In my case, with fish shell or bash history search with fzf, I&#x27;ve effectively created a cheat sheet of commands I frequently tend to use with working examples. Seems to be working for me so far.

Git has its quirks, but the underlying model is good.<p>There&#x27;s some naming problems, like I just had to explain lightweight tags vs annotated ones to some newbies.<p>The lightweight ones should have had a different name, like &quot;bookmarks&quot; or something.

Try JJ: <a href="https:&#x2F;&#x2F;github.com&#x2F;martinvonz&#x2F;jj">https:&#x2F;&#x2F;github.com&#x2F;martinvonz&#x2F;jj</a>

`git rebase --onto FIRST_ID^ NEW_PARENT`<p>is also super powerful to put a series of commits on top of a new parent when history has changed.<p>That happens with PRs and squash merges quite often.<p><a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;29916361&#x2F;1000145" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;29916361&#x2F;1000145</a>

&gt; Find every commit that added or removed some text &gt; git log -S banana<p>I literally spend half an hour the other day having an argument with chatGPT about how I could find versions of a file that contained a specific string. Guess I should have asked for commits and not versions of files.

Julia Evans&#x27; content is always high quality.

i have many aliases [1] for everything i ever need to do in git, serves me great for the past couple of years<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;looshch&#x2F;configs&#x2F;blob&#x2F;master&#x2F;.gitconfig">https:&#x2F;&#x2F;github.com&#x2F;looshch&#x2F;configs&#x2F;blob&#x2F;master&#x2F;.gitconfig</a>

Are there git alternatives that aren&#x27;t a PITA to master before one can use them in production?

this is a better one: <a href="https:&#x2F;&#x2F;medium.com&#x2F;@lordmoma&#x2F;so-you-think-you-know-git-673f9c4b0792" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@lordmoma&#x2F;so-you-think-you-know-git-673f9...</a>

For listing branches, git branch -vv gives some more info.

the one thing that is handy and missing here is creating and pushing tags.

git reset HEAD is nifty way to unstage everything! Really cool!

These cheat sheets are a great idea spoiled somewhat by the use of an infuriatingly annoying-to-read font.<p>If your mission is to make hard topics <i>easier to understand</i>, why are you using a hard-to-read font whose only purpose is to make the cheat sheet look folksy?

git fetch origin &lt;branch_name&gt;:&lt;branch_name&gt;<p>to update a branch while you&#x27;re on another branch

She delivers, yet again.<p>Thanks!