Hacker News new | comments | show | ask | jobs | submit login
Git Cheet Sheet (git-tower.com)
83 points by javinpaul 1608 days ago | hide | past | web | 18 comments | favorite

The "Test Code Before You Commit" rule suggests that the writer does not distinguish between committing code and pushing code, between private changes and public changes. When you commit changes locally, you can always rebase to your heart's content before pushing.

I think this says it best: "Treat public history as immutable, atomic, and easy to follow. Treat private history as disposable and malleable." https://sandofsky.com/blog/git-workflow.html

"Test Code Before You Push" seems to be what they're trying to say.

I think as long as you are working on a feature branch you can even push it to the server. Better than locked up on your own machine and more robust to machine failure. I tend to push to at least two servers frequently (github or bitbucket and my own gitolite installation on a VPS).

Obviously don't push to master or any shared mainline branch until it is done. When using github with others (even one other) I prefer to only merge to master with Pull requests so there is opportunity to review and comment on the code as a second pair of eyes.

I maintain a very basic cheatsheet (https://github.com/trufa/git-cheatsheet) if anyone is interested, I think it is a little bit more helpful since it links to relevant explanations and has some clarifications beside the code.

I did it for myself (because I kept forgetting) so it's not very thorough, but still a little more helpful if you ask me, it will get better with time and/or collaboration (unlike an image!).

Note that the very basics are not included, those you tend to remember them soon enough IMO.

If you're interested it's hosted on github and I would be very happy if anyone want's to collaborate:


Why don't you put a rendered version on a GitHub page[1]?

[1] http://pages.github.com/

I hadn't done it because it's very home-made, but since it's effortless, it's already done. Thanks for the suggestion!


I like this. Thanks for sharing! Starred at GH.

In case you don't want to download all three design variations in a zip file you can download the one you want here:

* White http://www.git-tower.com/files/cheatsheet/Git_Cheat_Sheet_wh...

* Grey http://www.git-tower.com/files/cheatsheet/Git_Cheat_Sheet_gr...

* Dark http://www.git-tower.com/files/cheatsheet/Git_Cheat_Sheet_da...

What font are they using for their cheat sheet? It appears to have its apostrophe glyph turned upside down, which seems a rather odd thing for a font designer to do.

EDIT: Actually, it looks like the font is fine and (for some reason) the source document represents apostrophes with U+2018 (LEFT SINGLE QUOTATION MARK) instead of U+2019 (RIGHT SINGLE QUOTATION MARK).

"Version Control is not a backup system"

I think it is. In fact, when working on personal projects that's the ONLY reason I use it.

I don't understand why Linus gets his knickers in a twist about the commit message thing. Whilst I do try and keep my commit messages useful and not blank, I can only think of three or four times in the last ten years where I've actually had to go back through previous versions of code to try and understand the current code. Why is it so important? Just look at the code you have now and fix it!

> I can only think of three or four times in the last ten years where I've actually had to go back through previous versions of code

Then, with all due respect, you work on some pretty trivial code and/or throwaway projects without long lifetimes. No one who has ever faced a serious regression in a large system would ever say something like this.

I think you'll find I work on full scale enterprise systems with lifetimes of 4 years - 30 years. It's about understanding the code you have now, and you can do that by looking through it.

This is going to be a nice thing to reference. I think I'll print it out. My only complaint is that it doesn't cover the git stash commands. I'll just use a good old fashioned pen to write my own section!

For the love of all that is spelling, will a mod change the title on here... it should be "Cheat" not "Cheet"

the popularity of these cheat sheets every month is telling of git's confusing, over-overloaded syntax :(

i keep hoping they make a clean break and just rework the commands to reduce confusion and introduce better uniformity

This. A million times, this.

FINALLY! Thanks you javinpaul for posting this. I really needed it!

git config alias.cheet cheat

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact