7 ms·
Git Cheatsheet
- gum_ina_package 13y agoIs anyone else getting tired of seeing all these "git tips", "cheatsheets", and "helpers" on here? While these all may look cool and be flashy, I've never used a single one that's showed up on the front page. Personally, I find the man pages + Google to be good enough. Then again, maybe I'm a curmudgeon.
- sergiotapia 13y agoYes, yes you are because man pages are _terrible_ to read especially if you don't know what to even look for. I can see them being useful if you are already familiar with the product and just want to double check what a feature does; but as a newbie? Showing me the man pages would make me want to bail. "How can I marge this branch to master?" "Just check the man pages." "But what am I looking fo-" "Man pages."
- _ikke_ 13y agoI see the manpages mainly as reference, not as initial introduction.
- CodeMage 13y agoYou're not a curmudgeon, but I'll wager you've been using git for a while now. Here's the problem I have with git -- it has one of the worst CLIs I've ever seen. Many command names are counter-intuitive, i.e. they don't do anything that you would assume from the name alone. To make things worse, most commands can do rather different things depending on the command line switches. This is all something that people can get used to, but the problem spills over from CLI into GUIs, because GUI authors try to make their programs more newbie-friendly and use more sane command names and lingo. As a result, no two GUIs will use exactly the same names for the same actions. So imagine a newcomer to git, who starts using a GUI and gets used to its lingo. Unfortunately, that newcomer can't easily communicate with other people who use other GUIs or CLIs. Worse, sooner or later the newcomer will have to resort to using the CLI or a combination of different GUIs, because there's always some useful git feature that you either can't do in the GUI or is an order of magnitude easier to do from the command line. That, in my not-so-humble opinion, is the worst problem with git. To me, this is sort of tragicomic, because git is absolutely the best VCS I've ever used.
- davvid 13y agoAs an author of a Git GUI, I've thought about this problem a lot. git-cola is quite user friendly, but its target audience is specifically power users (I wrote it for myself). I don't like dumbing things down for new users. If you think about it -- targeting new users is not the ideal for a maker-centric tool. A master chef uses the sharpest knife around. The new chef is only new for so long before he graduates up.
- unethical_ban 13y agoI found Bzr much easier to learn than Git, and I'm not aware of architectural powers that Git has which bzr doesn't.
- MBlume 13y agoMy recommendation is always just to read Pro Git from cover to cover.
- lttlrck 13y agoMe too. This is an excellent resource. Cheat sheets hide what is happening and thus limit understanding.
- justinhj 13y agoNo I'm not tired of it at all. I think it is more than cool and flashy, as it does a great job of showing how changes move between each part of the repo. This is great for beginners. The man page and google is good enough, but this is a great addition.
- austenallred 13y agoI wish I didn't have to click on each topic to see it, but as someone just learning to program this is extremely valuable.
- chewxy 13y agoWow, this is actually good use of visualization. I clicked through expecting a one pager. Instead, I got an interactive cheatsheet showing how the commands interact across different repos, indices, and workspaces.
- theg2 13y agoI'm actually of an opposing viewpoint about the visualization. It gets in the way of the information, why does this even need to be visualized and stylized? I know git is anything but stylish but this feels like visualization for the purpose of visualizing something.
- aidos 13y agoI disagree. When I explained git (as best I could) to a friend I drew something similar, though less detailed, on the whiteboard. It helps to see the different spaces an the commands that push files between those spaces. I found the visualisation useful in this case.
- andrelaszlo 13y agohttps://github.com/ndp/git-cheatsheet https://github.com/ndp/git-cheatsheet Site seems down. Just clone this repo and open git-cheatsheet.html in your browser.
- x3c 13y ago<strike> If the author has not labelled it opensource, should you be cloning it's source code (unless of course, you're the author)? </strike> Edit: Sorry, just researched it, you're linking the repo from the author's git account.
- deleted 13y ago[deleted]
- daddykotex 13y agoVery good work here, it is interesting to think of it in a visual way.
- lmm 13y agoMy awkward git use case: while working on a branch, I frequently want to merge changes from the (upstream, remote) master into my branch. Is there a faster way to do this than switch to master, pull, switch back, merge master?
- itafroma 13y agoStrictly speaking, you can pull from any remote branch directly: git fetch remotename git merge remotename/master But you usually just want to rebase your changes onto the latest HEAD: git fetch remotename git rebase remotename/master Merging will place the remote branch's changes after yours, which will make your history a nightmare, especially if you're going to continue working on your branch. Rebasing will place your local branch changes after the latest changes to the main branch.
- kyleslattery 13y agoYou can even collapse the first one into a single command: "git pull remotename master"
- raimondious 13y agoAnd the second one too: "git pull --rebase remotename master"
- _ikke_ 13y agoNote that in this case, your remote tracking branches wont be updated, so git status will say you are ahead of the remote, while you are in fact at the same point. A "git fetch <remote>" would then update the remote tracking branches.
- jedbrown 13y agoIf you are using topic branches, it's bad practice to merge from upstream when it is not necessary [1,2,3], because you clutter your branch with new features that are mostly unrelated to what you are trying to accomplish. Consider merging the specific topic branch that you need rather than 'master'. Alternatively, if nothing depends on your branch yet, you can rebase onto 'master', though this may invalidate earlier testing. Now to your specific question (fast-forward a local branch without checking it out), you can git fetch origin master:master or git push . origin/master:master Then you can merge 'master' instead of 'origin/master', thus eliminating the remote URL or "remote-tracking" language from the prepared commit message. [1] http://gitster.livejournal.com/42247.html http://gitster.livejournal.com/42247.html [2] http://lwn.net/Articles/328436/ http://lwn.net/Articles/328436/ [3] http://yarchive.net/comp/linux/git_merges_from_upstream.html http://yarchive.net/comp/linux/git_merges_from_upstream.html
- nakovet 13y agoIt's missing the staging area, but it looks good and well done.
- datr 13y agoThey're using the term "index".
- benburleson 13y agoThey're calling it Index. I agree, staging area makes more sense.
- mbaird 13y agohttp://3d247fe.5minfork.com/git-cheatsheet.html http://3d247fe.5minfork.com/git-cheatsheet.html
- dgregd 13y agoGreat visualization. It actually shows how messy is git command line interface. Just looking at a cmd syntax it is hard to guess if the cmd refers to workspace, index or local repository.
- ozh 13y agoWell that's because the command may refer to any of these In case you don't know this humorous tale, read and enjoy the part about `git checkout` http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/
- Trufa 13y agoA plug to my cheatsheet, it is just a repo in github: https://github.com/trufa/git-cheatsheet https://github.com/trufa/git-cheatsheet I try to link to the relevant StackOverflow explanation- I'm adding new stuff every now and then. This weekend I'll organize it and add some obvious stuff that is missing and publish it to HN. I honestly find it more useful that most of the cheat sheets, specially those images with a couple of commands written on it. Please feel free to collaborate pull requests and or issues are greatly appreciated.
- d_theorist 13y agoI really like this because it shows the different 'places' things happen in Git arranged spatially, and groups commands into those spaces. This really helps with building mental model of how things work. The visualization is great and a lot of fun but I would also like to have a non-interactive version for quick paper-based reference.
- sdfjkl 13y agoI just gave up and use SourceTree. I don't like git's syntax at all, but have to work with it, so a nice GUI works best for me. Maybe I'm getting old, or maybe I just prefer a better designed command line interface (for my personal projects I'm using Fossil and am quite happy with the command line there.)
- webjunkie 13y agoSourceTree is the best. Without it, it is easy to get lost with Git.
- Tyr42 13y agoI am normally just a command line guy, but I really do prefer SourceTree for merging and moving/visualizing branches. And it makes it nice to add only hunks of a file.
- wise_young_man 13y agoI found out about SourceTree after I had already learned the commands and it improved my productivity a ton, I can do everything faster with it and rarely use commands. It has so many features baked in it is amazing. Huge props to Atlassian for buying it and making it free. It is now my goto recommendation for anyone getting into Git.
- scorpion032 13y agoI used to use SourceTree. I moved to using GitX: http://rowanj.github.io/gitx/ http://rowanj.github.io/gitx/ and seem to prefer it much more. SourceTree feels too cluttered. Gitx has better UX and appeals to me as someone that prefers to view more relevant content on the screen.
- greyboy 13y ago> Gitx has better UX and appeals to me as someone that prefers to view more relevant content on the screen. ... and has a Mac, of course, which rules it out for many of us (though I can't speak for the sdfjkl).
- Flimm 13y agoPlease don't break my back button.
- FourEdenSix 13y agoThe site is built using internal links, it no more breaks the back button than wikipedia's contents section does.
- Already__Taken 13y agoIt's not listening for changes to the URL so going back through the URL does not change the pages state. This is breaking the point of the back button and URL. If you click through a long Wiki page you'll see presing back does indeed move you back. Back is broken it just isn't hijacked.
- ndp8 13y agoYep, it should redraw the page when you hit the back button. I'll fix it. -- nd
- jlgreco 13y agoI have to press the back button several times to get off of this site (after clicking on this site several times). Each time I press the back button, I am given no visual feedback from the site (unlike on wikipedia, where I am scrolled through the page as I press "back"). This page certainly does break the back button.
- nilkn 13y agoWhile that may technically be true, it's a problem because it violates user expectations. It makes sense that clicking a link on Wikipedia's contents section would update the URL, but I think it is much less clear that interacting with this page should change the URL for every click.
- mmabbq 13y agoThis is pretty neat, but I find it pretty annoying that my eyes have to keep shifting up and down to read the explanation for each command. It would be nice if the explanation text popped up closer to where my eyes are already focused.
- pjmo 13y agoAwesome, thanks!
- jhdevos 13y agoSmall fun bug: if you click twice on an item, the description at the bottom shows 'git null' :)
- rjzzleep 13y agoI once again want to remind people of tig[1]. While there are plugins like gitv that do similar things, i prefer tig. You can set custom hotkeys in your tigrc (which are context sensitive). For example: bind generic F !git fetch bind main ! !git revert %(commit) bind main c !git checkout %(commit) [1]http://jonas.nitro.dk/tig/ http://jonas.nitro.dk/tig/
- yeukhon 13y agoNice visualization idea but the color is burning my eyes... and to be honest the best cheatsheet is a table format. Easier to search and navigate.