Git Cheatsheet

Yes, 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."

You'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.

My recommendation is always just to read Pro Git from cover to cover.

No 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.

I'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.

SourceTree is the best. Without it, it is easy to get lost with Git.

I 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.

I used to use SourceTree. I moved to using 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.

> I just gave up and use SourceTree. I don't like git's syntax at all, but have to work with it

There's also the hg-git option, may work well enough for you.

Using a GUI is a great way to get your feet wet. One challenge with git is simply getting an intuitive understanding of how parts of the system relate to each other. After some time in SourceTree, it is possible you'll start to appreciate the flexibility of the CLI and maybe even find a place for it in your workflow.

The site is built using internal links, it no more breaks the back button than wikipedia's contents section does.

Strictly 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.

If 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

[2] http://lwn.net/Articles/328436/

[3] http://yarchive.net/comp/linux/git_merges_from_upstream.html

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

tig is so handy that I'm almost incredulous when people tell me they've never used it or heard of it.

Well 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/

They're using the term "index".

They're calling it Index. I agree, staging area makes more sense.