Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git cheat sheet [pdf]

wizardzines.com

Post reply on HN
Print view View original

71–80 of 146 posts

Re: Git cheat sheet [pdf]

#71

Post by fragmede »

vrinsd wrote: post #16
Zambyte wrote: post #9

Earlier quoted context omitted.

After learning Jujutsu, I realized this is really wrong. The underlying data structures and operations are great, and they serve their purposes really well (such as supporting 10k+ people collaborating like you mentioned). They are what makes git great. The git command line interface is a needlessly complex abstraction on top of them that tries to encourage certain behaviors, but does a really bad job at it.

100% agree. The fact there are 5 different ways to do the same thing is BAD, not good. Have one well defined, documented clear way to solve a problem.

There are 3 different ways I could get to the store, I could walk or drive or bicycle. There are also 3 different paths I can take. I could go down road A, sidestreet B, or alleyway C. I know you'd rather one big button to press that just says "do it" on it, but in order to perform complex actions on complex objects, there are going to be multiple ways to accomplish the same thing.

Re: Git cheat sheet [pdf]

#72

Post by rezonant »

One thing missing that I use all the time, "git cherry". Without arguments it will show you what commits in your local branch are not in your remote tracking branch. Use "git cherry " to list the commits in the current branch that are not in the given ref.

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/promotion branches.

Super useful, I thought everyone used it but maybe some don't know!

Re: Git cheat sheet [pdf]

#73

Post by mwpmaybe »

ruraljuror wrote: post #8

Love this. I would add: git commit —-fixup $COMMIT_ID combined with git rebase -i upstream/master —autosquash 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.

Ahh, thank you:

    git commit —-fixup $COMMIT_ID
I'm adopting this immediately. I always make little "oops " commits like "oops GET users/me" and then manually move and fixup them on my next interactive rebase. This is much better!

Re: Git cheat sheet [pdf]

#74

Post by erik_seaberg »

vsnf wrote: post #56
acjohnson55 wrote: post #39

Earlier quoted context omitted.

The skillset to navigate this is one of the underappreciated challenges of teaching.

Exactly zero of my mathematics professors, and a large portion of my CS professors managed to adequately account for this. The professors of mine who did manage it remain firmly in my memories as great people and great teachers, while the one's who didn't inhabit an area between complete memory erasure, and disdain for how hard they made my life. This is at the very core of what it means to be a teacher, not just kno…

> In the middle of delivering a lecture, Hardy arrived at a point in his argument where he said: "It is now obvious that..." Here he stopped, fell silent, and stood motionless with furrowed brow for a few seconds. Then he walked out of the lecture hall.

> Twenty minutes later he returned, smiling, and began: "Yes, it is obvious that..."

Re: Git cheat sheet [pdf]

#76

Post by abalone »

This is great, especially the little diagrams which help illustrate rebasing vs merging, one of the tricker parts of the git learning curve.

Having said that I think it could more clearly state the author's typical preferred practice for updating a branch and integrating it with main when you're done. There's a few techniques listed for diverged branches, but then fast-forward merge is in its own box and it's not super clear how you might use working-branch rebasing with it to eliminate divergences in the first place (even though it's hinted at under "pull changes").

I wonder if it would be clearer to say something like "combining branches: rebase your branch and do a (FF) merge, optionally with squashing," or however they like to do it.

Re: Git cheat sheet [pdf]

#77

Post by koito17 »

Cool cheat sheet, especially because it covers common use cases. But practically everything covered here I was able to learn independently with Magit. It'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.

Re: Git cheat sheet [pdf]

#78

Post by redbell »

"There are only two hard things in Computer Science: cache invalidation and naming things." - Phil Karlton [0]

Based on the above statement, I find it extremely weird to see such git command named "blame", then I realized I'm not the only one:

What does 'git blame' do? [1].

Blame someone else for your bad code [2].

Git blame should be called git credit [3].

Does Git Blame sound too negative? [4].

______________________________

0. https://skeptics.stackexchange.com/questions/19836/has-phil-...

1. https://stackoverflow.com/questions/31203001/what-does-git-b...

2. https://news.ycombinator.com/item?id=27963868

3. https://dev.to/damcosset/git-blame-should-be-called-git-cred...

4. https://www.reddit.com/r/ProgrammerHumor/comments/r5lzyo/doe...

Re: Git cheat sheet [pdf]

#79

Post by erik_seaberg »

wakawaka28 wrote: post #58
vrinsd wrote: post #14

Earlier quoted context omitted.

Yes. Because git was created by Linus Torvalds specifically to enable and advance Linux kernel development. The fact it has become so widly adopted is a "happy accident" (or misery). Github I think has been widely credited with making git so common place ("free git hosting") but I don't think git is the "ideal" revision control system for many projects. Because it was made for Linus for Linus/Linux, this is why the t…

> Mercurial got the "user interface" and command-set right and has some nifty features (being able to launch a web server on the fly to get a tree view of your changes) but being written in Python, performance and scalability aren't ideal. I used to think Mercurial had a better UI but I changed my mind after taking the time to understand Git. Mercurial does have nifty features but Git's way of working isn't hard or e…

Yeah, I'd heard good things about the Mercurial UI but bounced off when "how to branch" turned up https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-m... with not one but three radically different answers. Seemed somehow unfinished to me.

Re: Git cheat sheet [pdf]

#80

Post by KennyBlanken »

These cheat sheets are a great idea spoiled somewhat by the use of an infuriatingly annoying-to-read font.

If your mission is to make hard topics easier to understand, why are you using a hard-to-read font whose only purpose is to make the cheat sheet look folksy?

Post reply on HN