[HN Gopher] Git Commands Explained with Cats (2017)
___________________________________________________________________
Git Commands Explained with Cats (2017)
Author : tosh
Score : 197 points
Date : 2021-09-18 12:01 UTC (10 hours ago)
(HTM) web link (girliemac.com)
(TXT) w3m dump (girliemac.com)
| voodoochilo wrote:
| Embarrassing.
| AndrewOMartin wrote:
| 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.
| shimonabi wrote:
| Exactly. I use basic git daily, but I'm still confused about
| rebase.
| xorcist wrote:
| 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.
| frutiger wrote:
| 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
| \----*----*
|
| to 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.
| [deleted]
| and0 wrote:
| 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.
| stinos wrote:
| 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.
| rusk wrote:
| 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.
| grayclhn wrote:
| This is great. IMO "replay" is a much better description
| than "copy."
| rusk wrote:
| 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.
| bloopernova wrote:
| 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.
| bentcorner wrote:
| 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`.
| gfodor wrote:
| 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.
| mhh__ wrote:
| 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
| [deleted]
| [deleted]
| pelagic_sky wrote:
| 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.
| tempodox wrote:
| Agreed. Explanations of git sometimes remind me of monad
| tutorials.
| contravariant wrote:
| 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.
| lvass wrote:
| Git is simply a directed acyclic graph of commits with
| pointers, stashes, a few named data stores and two quasi-
| recursion mechanisms.
| CrazyPyroLinux wrote:
| "It's like a burrito!"
| PebblesRox wrote:
| For the unfamiliar: https://www.google.com/amp/s/byorgey.wo
| rdpress.com/2009/01/1...
| isaacimagine wrote:
| 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
| aught wrote:
| This is inspiring morning reading for my study day. Seeing posts
| like this always motivates my note taking.
| scott_paul wrote:
| 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.
| dgfitz wrote:
| Oh how I wonder how different things might be if mercurial won
| the dvcs wars.
| mdaniel wrote:
| "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
| pacomerh wrote:
| cute cats but this is kinda confusing
| nobodyandproud wrote:
| 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.
| einpoklum wrote:
| You could try this article:
|
| https://www.codemag.com/article/1105101/Git-for-Subversion-U...
|
| caveat: I have only skimmed it.
| ape4 wrote:
| Git commands are confusing. Hopefully they'll be renamed or a
| neogit will do it better someday.
| richardfey wrote:
| I abhor the related debate, but I wish she had used 'main'
| instead of 'master' (to avoid further debates)
| barefeg wrote:
| Nice illustrations but I find it actually harder to understand
| even though I'm completely familiar with the concepts
| squarefoot wrote:
| 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.
| SwiftyBug wrote:
| Maybe the problem is that you're not familiar with cats?
| [deleted]
| einpoklum wrote:
| 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.
| chaboud wrote:
| 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?
| kjhughes wrote:
| 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...).
| corprew wrote:
| 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).
| BrandoElFollito wrote:
| 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.
| smusamashah wrote:
| 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.
| wegs wrote:
| 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.
| dharmaturtle wrote:
| re: navigation:
|
| VS Code can render PNGs, so you can hit the period key on
| GitHub and just navigate the repo's PNG folders.
| SavantIdiot wrote:
| Really clear explanations. Much better than the git documentation
| that uses letters. Visual cues help a lot.
| mdaniel wrote:
| 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
| pm215 wrote:
| 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.
| na85 wrote:
| Using a modern shell like zsh allows for tab completion of
| those options.
| bdcravens wrote:
| You can of course create a git alias
|
| https://stackoverflow.com/questions/30542491/push-force-
| with...
| dan-robertson wrote:
| 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.
| na85 wrote:
| 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.
| u801e wrote:
| > 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.
| q-rews wrote:
| 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_
| BrandoElFollito wrote:
| 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/
| jimbob45 wrote:
| As a fellow Git-hater, TortoiseGit vastly improved my dealings
| with Git.
| dan-robertson wrote:
| Yeah, magit for me. But I feel there ought to be a better
| way.
___________________________________________________________________
(page generated 2021-09-18 23:01 UTC)