Git Commands Explained with Cats (2017) | Hacker News Reader

Git Commands Explained with Cats (2017)

girliemac.com

266 pointstosh64 comments

Open articleView on HN

See also her sketch notes on other topics (https://girliemac.com/doodles/):

- Introduction to Programming & Tools

- Machine Learning Regression

- Notes from Presenting Data & Information course by Edward Tufte

- Notes from The State of Web Platform

And her list of other Tech Doodlers & Sketchnote artists to follow (https://girliemac.com/blog/2021/07/12/microsoft-beginners-sk...).

Teaching new users about "--force-with-lease" may pay dividends over the less considerate "--force": https://git-scm.com/docs/git-push#Documentation/git-push.txt...

That is to say: I totally benefit from "git commit --amend && git push --force-with-lease" but 100% percent of the time want that flow to call time-out if someone has pushed before me

Unfortunately as UI a 7 character option is almost always going to win over an 18 character option. I know about --force-with-lease, I know that it would provide an extra safety guard, and I always use --force anyway because it's the short, easy to remember and quick to type one.

You can of course create a git alias

https://stackoverflow.com/questions/30542491/push-force-with...

Using a modern shell like zsh allows for tab completion of those options.

git push <upstream> +branchname is shorthand

Check out --force-if-includes … it works well in combo with —-force-with-lease and ensures you don’t accidentally replace a branch that is not yet merged into your current branch (force-with-lease has a pitfall where if you fetch before pushing, it’ll act like a straight up force push).

Hi, I am the author of the "Git Purr " doodles here.

This probably isn't for everybody but if you like tech && cats, I made "HTTP Status Cats" a long time ago too. I believe that one satisfies more of you.

http://http.cat

(I don't own the website or the awesome domain name, but the original HTTP Status Cats images are done by yours truly!)

Just printed your doodles and put them on one of our whiteboards.

Most of my fellow devs are from a 3D modeling and design background and have a hard time understanding anything more than push and merge (using a GUI). I tried to explain them numerous time, but they just phase out after a couple of minutes.

Nice illustrations but I find it actually harder to understand even though I’m completely familiar with the concepts

I'm not familiar with the concepts, save for the occasional git clone, and found it about impossible to understand. And i also love cats.

Maybe the problem is that you're not familiar with cats?

While the doodles are cute and colorful, I fear you have to already comprehend the subject matter to appreciate them. This is doubly true since the doodles are in fact pages laden with quite a bit of text.

I doubt there is a target audience which fails to comprehend the un-doodlified versions of these doodles, and is helped significantly by the cats and colorfulness.

For me, this is both accurate and appropriate.

We own four cats in our household, aged 16-25. So they’ve been around almost as long as I can really remember. In all that time, anything I’ve been capable of doing I do much worse and much more slowly when they are present. Playing piano, cooking dinner, writing code.. all crumble in the face of a cat that wants a warm lap (and won’t shut up about it).

Understanding git doesn’t feel any different, just more extreme. Anyone who tells you that they fully understand git is mistaken, lying, or named Linus. How is adding cats going to fix that?

If only we could instead have an intuitive version control system which didn’t need crazy explanations or for each team to have a ‘git expert’ who has memorised a few more commands for unbreaking the repo than anyone else. But for now, it seems git is here to stay and many collective hours will be wasted cursing the git who designed it.

As a fellow Git-hater, TortoiseGit vastly improved my dealings with Git.

Yeah, magit for me. But I feel there ought to be a better way.

Me too, I use TortoiseGit almost exclusively. I have its log view open almost all the time and do all my git actions from there. I can get along in the command line but I'd rather not, my short term memory is awful.

I just like seeing the visual feedback of the actions I've just done.

I am an amateur dev who, for the last 10 years, is using 3 git commands with fingers crossed (because my only "git expert" is StackOverflow).

GitExtensions[1] vastly improved my life. It is a wonderful program.

[1] http://gitextensions.github.io/

Git is an awful tool but for most use cases it's much better than CVS, SVN, or perforce or something.

I wish the docs weren't so abysmally bad, and I wish it did a better job abstracting away the internals.

I don't have time to learn about git's arcane internal shenanigans. I just want version control.

> If only we could instead have an intuitive version control system

What makes git any less intuitive compared to svn or cvs? To use either of those or git effectively required reading through documentation to understand what each command did.

I have no experience with those, but the complaint is that there are a myriad of commands and flags and overloads that could basically amount to a handful of common operations and simple resolutions.

I myself have “no issues” with git but conflict resolutions are still a guessing game when they’re for middle commits

Typically git is compared to mercurial which is quite similar in many ways, but feels much simpler. It's been a while since I have used mercurial but I enjoyed it a lot.

Svn and cvs are centralized, which makes everything much more intuitive and easier to understand IMO. I also think they are simpler (centralization requires less commands)

> Svn and cvs are centralized, which makes everything much more intuitive and easier to understand IMO.

For both cvs and svn, creating branches, merging changes from different branches, and switching branches definitely were operations that required a few steps that would not be easy to figure out without reading through the documentation.

The only thing that git had that those programs didn't was the concept of a staging area, which, as I understand it, bazaar and mercurial didn't have (unless you created another copy of the repo or another branch to serve as a staging area). But the fact that people have tried to replicate that feature in the other DVCSs indicates that it's a desired feature, even if it does add some complexity compared to not having it.

This is one of those "explanations" where, if it's a concept I'm familiar with I can apply my knowledge to it and see that it mostly checks out, but if it's something I don't already know, I find completely useless.

Agreed. Explanations of git sometimes remind me of monad tutorials.

I suppose you could combine the two by pointing out that git is like a category where a git merge is like a pushout etc.

Git is simply a directed acyclic graph of commits with pointers, stashes, a few named data stores and two quasi-recursion mechanisms.

“A monad is just a monoid in the category of endofunctors.”

"It's like a burrito!"

For the unfamiliar: https://www.google.com/amp/s/byorgey.wordpress.com/2009/01/1...

Personally, as someone who has been sketchnoting for about 5 years, I feel the point of sketchnoting is more to create a condensed visual reference of an idea for personal recall than for teaching that same idea to someone else.

There's a wider argument here of whether notes should be used for personal recall or general reference. I tend to lean towards the former, but there's more nuance here.

I'm working on a blog post that discusses how to take good sketchnotes and breaks down this argument a lot further, but it's already super long and far from being finished... perhaps I'll finish it someday, haha.

Kudos to the original author of these notes. When taking these types of notes, you have to think about what to leave out as much as what to leave in. I think that concise notes in this style to show that the author has a deeper understanding of the subject than the notes convey on the surface, especially when the point of these notes are to compress one's knowledge on the subject into a concise visual representation.

Sketchnotes are macroexpand for the brain :P

Exactly. I use basic git daily, but I'm still confused about rebase.

I gave up. I determined some of us are just too stupid to do quantum physics or rebase in git without destroying our branch. I'm one of those people.

FWIW Git is harder to understand than basic quantum mechanics IMO.

The latter has been optimized with good notation and has a fairly simple structure, whereas Git is a beautiful idea wrapped in an API from hell

Rebase is copying a series of commits and pasting them onto somewhere else. By default it will copy commits and apply them onto the new upstream.

In other words, go from

            old                 your
           master              master
    ----*----*----A----B----C----D
              \        
               \          new
                \        master
                 \----*----*

            old               your old
           master              master
    ----*----*----A----B----C----D
              \        
               \          new                 your
                \        master              master
                 \----*----*----A'---B'---C'---D'

Interactive rebase allows you to choose to reorder, rename, combine or drop those commits A, B, C, D as they are applied to new master.

For me it's the other way around. I mean, it's like one of the few commands which says what it does: re-base. Makes all kind of sense to me: take what you have and put it on top of something else. So same as a bunch of cherry-picks, etc. It was one of the first concepts I undesrtood. Merge on the other hand I understand as well but it leads to graphs I can't understand without spending some time looking at.

Rebase is just replaying the diff associated with each commit. It’s like a batch cherry-pick and that itself might be a conceptually more straightforward place to start.

This is great. IMO “replay” is a much better description than “copy.”

Technically more appropriate than copy as a commit is immutably wedded to its history by the chain of hashes preceding it.

FYI replay is the term used in the git docs, which otherwise make little sense.

rebase cherry-picks more than one commit, as in "git reset c; for commit in a..b; do git cherry-pick $commit; done". With sensible defaults for a, b and c, they can often be left out.

Someone will correct me, hopefully, if I'm wrong:

Rebase means moving the branch point of your feature branch to later on the main branch.

Let's say you create feature branch foo from main on 2021-08-01. You do work. Others do work and add them to main. On 2021-09-18, you rebase foo onto main. This has the effect of re-writing history! There's no longer a branch point at 08-01, it's been moved to 09-18.

https://www.atlassian.com/git/tutorials/merging-vs-rebasing

Rebase is not always the best option. I personally prefer merging, and that has worked for 100% of situations I've found myself in so far in my DevOps career.

> Someone will correct me, hopefully, if I'm wrong:

> Rebase means moving the branch point of your feature branch to later on the main branch.

It refers to a more generic action/set of actions, where this description is one possible end result. Granted this is probably the most common use, and the name "re-base" definitely fits this usage best.

The more generic action is something like "take a set of commits in one place in the git history, and reapply them somewhere else in the git history, optionally dropping or rearranging some of them in the process".

It's strangely wonderful to me that people can have so many different ways of explaining this action/concept. Your description is definitely more accurate than mine :)

The most useful way for me to think about a rebase is "replay my commits over an updated branch, as though I started coding when those updates had already happened"

So if you check out on day 0 and rebase on day 5, then it becomes "pretend I started coding on day 5 in the first place, and let me correct any contradictions (conflicts) as though I was making those decisions as I was making each commit".

I still struggle but this helps me conceptualize it.

Tip: Create a new branch before you do the rebase, if you fuck up the rebase with bad merges or dropped commits it's easier (i.e. more intuitive) to unfuck by just using the backup branch you made prior to your rebase instead of messing around with `git reflog`.

As a designer. I don’t understand these. I know the overall concept of using git but this didn’t bring me any aha moments.

I think what this needs is a proper scan and vectorization.

Author has a nice repo with other doodles:

https://github.com/girliemac/a-picture-is-worth-a-1000-words

I really wish there were some way to find and navigate good OERs like these.

re: navigation:

VS Code can render PNGs, so you can hit the period key on GitHub and just navigate the repo's PNG folders.

I wrote this long time ago after having rough time learning basics of git myself https://xosh.org/explain-git-in-simple-words/

My qualm with most available explanations back then were that they all start from command line with no visual explanation.

Now if you understand that it's a linked list, where nodes link to previous node instead of next, branches and tags and everything starts to make sense.

I showed this to a non technical guy who is trying to learn git. He said he liked the cats but this didn't help him understand it any better.

Really clear explanations. Much better than the git documentation that uses letters. Visual cues help a lot.

This is inspiring morning reading for my study day. Seeing posts like this always motivates my note taking.

I was really disappointed when I saw this, but not because of the content, which is great, but because I saw Cats (Year) and assumed that the link was going to be explaining git using the _movie_ Cats. Sadly, the movie was Cats (2019).

For someone who knows the 3 git commands that allow for a basic usage, such illustrations acre completely useless.

There are zillions of introductory tutorials that are much easier to understand.

I wonder who the target audience for such drawings actually is.

Oh how I wonder how different things might be if mercurial won the dvcs wars.

"Slower," in my experience

I wonder if having Mercurial continue in python is a development advantage, or it just started out that way but now would benefit from a more performant version

Any good onboarding material for someone who comes from traditional (file-based) VCS?

I find git is just similar enough to older VCS systems trip one up dangerously.

You could try this article:

https://www.codemag.com/article/1105101/Git-for-Subversion-U...

caveat: I have only skimmed it.

To girliemac: do one for Docker please.

cute cats but this is kinda confusing

Git commands are confusing. Hopefully they'll be renamed or a neogit will do it better someday.

wow, two "I" for every sentence... "I have" "I am" "I studied" "I consider myself" so much ego

Reply on news.ycombinator.com