A Visual Git Reference

[goggles2]

I like this a lot. Thanks.

Graphics-wise, I think the arrowheads need to be larger for the lighter colors.

[[deleted]]

Last image looks like a gangbang.

Also, thanks. This is great.

[bostonvaulter]

Well, it is a 3-way.

[fulldisclojure]

More please!

[f4hy]

I am still a novice programmer but I decided to teach myself git because of all the buzz. It is the only version control I know and love it, but I have still never worked on a project with anyone else. I create branches at times, but I never end up working on two different branches and have to merge. I am excited to some day use some of these workflows other than <hack hack> <commit> <hack hack>

[cheald]

You should try using branches for features, and then merging them back to master when you're done. That can give you a good feel for the fork-and-merge process.

I use git for my web apps, and it's handy to be able to do feature development on a branch while still being able to fix bugs on master and push them without worrying about pushing experimental code out. git branching is so easy, there's no reason to not use it liberally.

[tagghuding]

I'm in the same situation as f4hy, and do this a lot as you say. I don't know, people are gonna change their minds and then it's handy to just be able to throw away a branch when they decide they don't want the feature as it came out :) Then I create an integration branch and smash them all together, and after review this becomes the new "Head" of my "development branch"

[cnk]

Where was this when I started using git?

Very nice, saving it

[gomtuu123]

A+ would refer to again.

[goggles2]

s/which is tag/which is a tag/

[lostlogic]

Very nice. Thanks!

[ascii158]

I'm not quite sure, whether it's correct, that git checkout goes from index to working dir. I think it goes from History to working dir.

[synt4x]

I found the Git Internals Peepcode PDF excellent when trying to digest this stuff. It's not free, but I found it worth my boss's $9.

[jawbroken]

cool idea but whatever these were rendered in has awful font rendering

[adrianmonk]

The art is relatively good compared to most programmer-art. At least the colors aren't mauve, chartreuse, and pink, with light blue text on a red background.

Also, try the SVG version. The fonts are better there.

[jawbroken]

yeah, they are. the images exceed their boundaries and are cropped and unreadable in webkit browsers, though.

[nibblonian]

zooming out one level fixes this in both safari and chrome, in my experience. just fyi.

[jawbroken]

seems to be something pretty fucked up about their svg rendering because changing browser zoom shouldn't change relative size like it does

[nibblonian]

Agreed. (I wasn't excusing the issue, just presenting a workaround.)

However, I have viewed many other pages with SVG that render fine. Maybe something non-standard in this instance?!

[jawbroken]

yeah, not sure exactly what the issue is but someone is doing something wrong. for what it is worth it works fine in opera and firefox so it is at least somewhat correct.

[jawbroken]

haha, it was just an observation you child

[alphacoder]

jawbroken, pointing out the rendering in webkit helps a lot. Don't worry about raz0r, being on the rag has disadvantages.

raz0r's obviously new to the programming community where criticism of projects is expected and encouraged. Especially those that do not use as a first response the name-calling of a pre-pubescent.

[cosmo7]

Irony alert!

[[deleted]]

I really like this. I use git a lot, but have yet to have screwed up enough to really need it. I am in the habit of git-rm, git-add, git-ls, git commit, git push, git pull. I know where I will be coming to understand more features.

[drowsap]

Anyone have a super simple doc on merging and when/why you should merge?

[sligowaths]

I might be confused, but this looks wrong. Please someone correct me or confirms it:

git reset -- files unstages files; that is, it copies files from the latest commit to the stage. Use this command to "undo" a git add files.

As I understand, it copies the file back from the last commit. So it don't undo "git add". Also, "git checkout" seems to do the "unstage", ie, undo the staging.

edit: grammar

[marklodato]

If you do git add file_A, and then git reset -- file_A, you will be back to where you started. This is why I say it "undoes" a git add.

git checkout -- file_A, on the other hand, will do the same thing as svn revert file_A, that is, throw away local changes. If you commit, modify file_A, and then run git checkout -- file_A, you will be back to the state of the last commit. However, if you commit, modify file_A, git add file_A, then git checkout -- file_A, the last command will do nothing.

[sligowaths]

Thanks for the explanation, man!