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

51–60 of 146 posts

Re: Git cheat sheet [pdf]

#51

Post by Zambyte »

lacedeconstruct wrote: post #20
SoftTalker wrote: post #7

Earlier quoted context omitted.

All I know of git is clone, pull, commit, and push. That’s all I’ve ever needed. Git can be that simple. Of course it supports more complex uses, which you can learn if you need them.

Life is simple until we play with time, once you start altering the past everything falls apart

It's not possible to alter commits with git. They are immutable. You can only make new commits that are based on existing ones in some way. The distinction is important, because the original commit (such as a commit pre-rebase) still exists after it's been "changed".

Re: Git cheat sheet [pdf]

#52

Post by bpugh »

dryanau wrote: post #44
therealdrag0 wrote: post #11

Earlier quoted context omitted.

Btw I moved from Sourcetree to Fork. It’s very similar but way more performant and smooth UI (unless ST has improved in last few years)

I like GitKraken, except for the fact that it lacks the ability to show first parent only, i.e. `git log --first-parent`. That feature is available in Visual Studio and Visual Studio Code (Git Graph extension), but I don't like these as much as GitKraken, so I end up switching between command line, GitKraken and VS/Code. It's a bit of a mess. Does Fork support `--first-parent`? It's especially hand in merge-heavy wor…

Not only does Fork support --first-parent, but it even lets you expand/collapse any merge commit just by clicking the node in the graph! Agreed it's the best way to make sense of a merge-heavy history.

I highly recommend Fork.

Re: Git cheat sheet [pdf]

#54

Post by fragmede »

Zambyte wrote: post #9
fragmede wrote: post #5

Earlier quoted context omitted.

It's not needlessly complex. The workflow it was created to support is inordinately complex, and the target market for that is highly technical, so its complexity was not the issue. Kernel developers needed to communicate to other kernel developers in a decentralized manner, and needed to work on top of each other. How do you work on a project where there are 15,000 people writing code? Git was created for this purpo…

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.

I'll have to dig into https://github.com/martinvonz/jj hadn't heard of it before. Either way, there's an underlying data structure with operations to be performed on, the interface to it is shit, and learning the underlying data structure makes it all make sense.

Re: Git cheat sheet [pdf]

#55

Post by wakawaka28 »

8n4vidtmkvmk wrote: post #23
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…

There's a C version of hg, and more recently a rust version. I can't say how much faster they are though

I don't think those other implementations were ever finished.

Re: Git cheat sheet [pdf]

#56

Post by vsnf »

acjohnson55 wrote: post #39
nomilk wrote: post #32

Earlier quoted context omitted.

> knowledge makes it hard to comprehend the difficulties other people have The phenomena you describe is known as the Curse of Knowledge [1] Wikipedia gives an example: A knowledgeable professor might no longer remember the difficulties that a young student encounters when learning a new subject for the first time. [2] [1] https://academia.stackexchange.com/q/163747/132074 [2] https://en.wikipedia.org/wiki/Curse_of_k…

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 knowing the material, but knowing how to teach the material. I consider many of them to be failures at their main job for failing to navigate the curse.

Re: Git cheat sheet [pdf]

#57

Post by dtgriscom »

sirentdiver wrote: post #33
Panzer04 wrote: post #28

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'd like to think I largely understand how it works. Its nice to recognise pretty much every operation on this cheatsheet. Is it common that developers still have issues with git after using it pro…

> Admittedly, I still have trouble remembering the commands to do what I want (hello, rebase --onto A B C), though :P. I work at a company where every developer uses Sourcetree, a GUI for Git. I don't really have a need to remember Git commands (and what arguments they take) anymore after using a GUI. For me, it is sufficient to know what Git commands do without knowing the semantics.

I always use SmartGit, another GUI. (I've lauded it to all and sundry, but have yet to inspire a new devotee...)

Re: Git cheat sheet [pdf]

#58

Post by wakawaka28 »

vrinsd wrote: post #14
tiffanyh wrote: post #2

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

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 especially counterintuitive. You must learn the terminology to properly understand it, but after that it's smooth sailing. Git actually has fewer moving parts than Mercurial, as there are less extraneous features. Instead of 3 or more categories of "branch-like" graph structures like Mercurial, you get branches as refs in Git. Every named leaf in the commit graph is a branch or a tag, and those have simple properties. There are surely git plugins to add more metadata but you don't really need that.

Git too has a web interface by default: https://git-scm.com/docs/gitweb Of course there are many Github-like solutions specifically catered to hosting repos and entire project workflows with Git too.

Re: Git cheat sheet [pdf]

#59

Post by Falimonda »

nomilk wrote: post #13

A couple of hidden gems: git diff --staged (shows the diff between the last commit and what you've got staged, great when what you're staging is finicky, lets you double check that you have precisely the files/hunks you intended) git log (git log, but for just commits where was touched; saves pilfering through all of git log, especially useful when the file only gets modified infrequently) Random tip: when using git…

I find aliasing a lot of these saves me a good chunk of time and reduces the barrier to better organize my work.

In case anyone cares to browse or suggest their own: https://gitlab.com/Falimonda/gitrc

Re: Git cheat sheet [pdf]

#60

Post by _blz2 »

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've effectively created a cheat sheet of commands I frequently tend to use with working examples. Seems to be working for me so far.
Post reply on HN