Live data from Hacker News

Git cheat sheet [pdf]

wizardzines.com

111–120 of 146 posts

Re: Git cheat sheet [pdf]

#111
post #40
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…

Wow, TIL `git diff --staged` exists and is an alias to `git diff --cached`, which I have used for many years. "staged" certainly feels more intuitive, but will I ever be able to undo this muscle memory?!

Same here. Just make it an alias: ds.

I’m using git dc, but it seems ds may be my new one, haha.

Re: Git cheat sheet [pdf]

#112

I liked the way I learned git. I started with sourcetree, a third party git gui. Super simple to use and understand. Then I moved to git gui, this step could be skipped. Then I got tired of pulling up my UIs and learned the terminal commands. Highly suggest this for anyone new, but just my (n=1) experience.

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.

I'd add Stash, unless I'm working alone

Re: Git cheat sheet [pdf]

#113
post #91

this is a better one: https://medium.com/@lordmoma/so-you-think-you-know-git-673f9...

Unfortunately, this requires creating a Medium account and signing in. Maybe it also requires payment later on. This is the message I see. > The author made this story available to Medium members only. > If you’re new to Medium, create a new account to read this story on us.

Non login-walled link:

https://webcache.googleusercontent.com/search?q=cache:https:...

Re: Git cheat sheet [pdf]

#114
post #9
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.

So where is the totally refactored/revamped CLI that applies Occam's Razor ?

Re: Git cheat sheet [pdf]

#115
post #102

Earlier quoted context omitted.

> 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 e…

Lol if you can remember how to use ImageMagick and Ffmpeg but not Git, I don't get it. Those programs do have very different argument passing styles than Git, but Git uses the same style as most every other unix/linux program. If you use it and know what you're doing, you should not be able to lose any work.

My advice to get over the hump you're on is to commit more often, check the status more often (`git diff [--staged]` and `git status`), and make sure you're branching or tagging enough to not lose commits. Then work on how to edit commits with `git rebase -i`. You can use rebase and cherry-pick to eliminate any unwanted commits or branches easily (notwithstanding conflicts, which are another critical thing to learn). If you feel like you messed up, you can almost always `git reset --hard` to the last commit you were on. If you forgot which commit you were on, there's the reflog. Generally, to be good at Git you have to take a few hours to learn it. It differs from the other programs you mentioned because there are different problems you can encounter at various points while using Git, whereas those other ones just succeed or fail and don't usually fail in unrecoverable ways (you just run them again until you're satisfied with the output). You can iterate on modifications to your commit history with Git but that is trickier and riskier.

There are many excellent Git tutorials online that explain everything an ordinary user needs, including rebases and the reflog. I think Github has one. Maybe that's what you need to figure it out, in addition to practice of course.

Re: Git cheat sheet [pdf]

#116
post #82
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 a better name would be “git praise”

One advantage that "git blame" has over possible alternatives such as "git credit", "git author", or "git praise", is that it's one character shorter and maybe faster to type.

For the same number of characters, I have heard of "git glory" as a possible alternative.

Re: Git cheat sheet [pdf]

#117
post #77

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.

I am just the opposite. I started using Git not long after it gained traction outside of the kernel project. Of course, it was primarily geared toward working in the terminal then. Some years later I had switched to Emacs and gave Magit a whirl. Even after going through quite a bit of its copious documentation, I just never felt comfortable with it. I guess I don't like being that far removed from the actual goings on with the repository.

I've since switched to Vim and happily use git at the terminal prompt. I doubt that will ever change as the interactive interface of various Git commands has improved.

Re: Git cheat sheet [pdf]

#118

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.

I'd add Stash, unless I'm working alone

Yeah even that has caused me trouble. I usually just copy the problem file to another directory, checkout the file from the repo, pull, and then diff/merge my changes. It may sound like more work, and maybe it is, but I understand what's happening and it's rare enough for me that to do it "the git way" I'd have to look it up every time.

Re: Git cheat sheet [pdf]

#119
post #77

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.

But it requires you to learn emacs. I thought I could just apt-get emacs and then from there do something to the effect of "install magit" and have a easy to use interface to git. I half a day later I gave up. Never got to install magit.

I had this exact experience trying to install Common Lisp. Installed emacs and wtfed out of there 30 min later having learned nothing and feeling slightly traumatized.

Re: Git cheat sheet [pdf]

#120
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.

The addition of `switch` and `restore` has probably reduced my daily cursing-at-git rate by half.
Post reply on HN