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

101–110 of 146 posts

Re: Git cheat sheet [pdf]

#101

Post by smusamashah »

pacoverdi wrote: post #98
smusamashah wrote: post #38

Earlier quoted context omitted.

I understand the commonly used core concepts of git pretty well, and using that knowledge, I can do exactly what I want using Git GUIs (IntelliJ these days). With CLI I can do pulls and commits at most.

IntelliJ has become pretty powerful with Git these days. Squashing, dropping commits, rebasing. Even interactive rebase can be done in a few clicks. I sometimes pop up IDEA to do some non-trivial cleanup in a repo. Even if relatively fluent with the command line, it saves me a lot of time.

What I like most, and isn't available in most UIs, is the ease of selecting individual lines you want to commit. Allows you to make very clean isolated commits most of the times.

Re: Git cheat sheet [pdf]

#102

Post by wruza »

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…

You must learn the terminology to properly understand it, but after that it's smooth sailing

This promise never held to me. I know the terminology and “how”, but it never got clear in my mind how to express day to day things which aren’t clone/add/commit/push. It’s just bad unmemorable ui that is both cumbersome to use and reason about.

I do have trouble remembering things but not like this with any other tool. For example, with ffmpeg and magick I could make them work without a manual. With git I can only damage things irrepairably.

Re: Git cheat sheet [pdf]

#103

Post by PhilipRoman »

PhilipRoman wrote: post #92
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…

I can confirm the part about rebase workflow, it really forces you to understand the git model. I sincerely recommend every dev to try it at least once. It also got me into custom power tools for git, like incremental rebase, dual blame, etc.

Too late to edit but I just realized we probably mean very different things by "rebase workflow". I meant making extensive use of Git history editing even on public branches, (with tags serving as backup). I guess the common meaning of "rebase workflow" is just using rebase instead of merge.

Re: Git cheat sheet [pdf]

#105

Post by tambourine_man »

sam_bristow wrote: post #68
tiffanyh wrote: post #2

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

Some of the complexity comes from the fact that in earlier versions it was reasonably expensive to add new subcommands. As a result more functionality got added to existing subcommands like git checkout. This made the UX more confusing. In newer versions of git the cost of adding new subcommands is reduced and they've started adding more specific commands like git switch.

Why was that?

Re: Git cheat sheet [pdf]

#106

Post by BossingAround »

pncnmnp wrote: post #65

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: "git diff > works.patch" Later on, you can apply it if necessary with "git apply works.patch".

You could use stash for just that use case (even multiple times to make multiple "patches").

For a more robuts method, you could also just commit (without pushing of course). Then, you can do "git reset --hard HEAD~1", and you have a pre-patch env ready for more work. When you need to re-do your commit, you can check reflog to get the ID.

Either way is, to me, an easier way to achieve the same result as patches.

Re: Git cheat sheet [pdf]

#107

Post by rswail »

Git has its quirks, but the underlying model is good.

There's some naming problems, like I just had to explain lightweight tags vs annotated ones to some newbies.

The lightweight ones should have had a different name, like "bookmarks" or something.

Re: Git cheat sheet [pdf]

#108

Post by TiredOfLife »

redbell wrote: post #78

"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]. _________________…

and off-by-one errors.

Re: Git cheat sheet [pdf]

#109

Post by Wowfunhappy »

redbell wrote: post #78

"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]. _________________…

I think `blame` is on-brand for a tool called `git`.
Post reply on HN