An introduction to git

I recently wrote this to a friend who joined an open source project, QRatitude, I started under the banner of Freeside Atlanta. Freeside is part of the reason I haven’t updated this blog in a good while, but I need to save my thoughts on that for another post.

This is a collection of really good resources on git (and perhaps, an outline of a future class I might teach).

I strongly recommend learn by doing when it comes to git, and starting with the absolute simplest concepts. It can quickly overwhelm you as an insanely powerful tool for historical changeset management on text and files.

Don’t worry about the terms thrown out here now. You’ll get to those in just a second. The goal is to learn enough to:

  • clone a remote repo
  • edit some files
  • stage the changes to the index
  • commit the changes to your local repo
  • pull from the remote repo
  • learn how to fix up any merge conflicts
  • push to the remote repo

http://gitimmersion.com/
Really easy and straight-forward, with few steps for each exercise. I recommend only doing labs 1-15.

http://www-cs-students.stanford.edu/~blynn/gitmagic/ch01.html
A well-written, entertaining and awesome introduction to version control in the general, as well as git. I recommend only looking at chapters 1-4.

http://osteele.com/images/2008/git-transport.png
Burn this image into your mind, and ignore all other diagrams that attempt to explain git in terms of commits and branches and arrows. If you get confused, keep this diagram open in a browser tab and look at it again.

http://git-scm.com/book/en/Getting-Started
From the git project itself, but you only want to read the first three chapters. Everything after that starts to go crazy.

The two most important concepts to remember about git are:

  • You have a staging area (the index) and a local repository (the local repo) on your machine, and a remote repository (the remote repo) on a server somewhere (say, github). The commands to put changes in each are add , commit , and push , respectively. Again, this diagram is god: http://osteele.com/images/2008/git-transport.png
  • Git helps you manage sets of changes, not files. When there is a merge conflict, it is not that one version of the file is different from another – git typically takes care of that for you. A conflict happens when changesets collide and you have to disambiguate.

Further reading and/or advanced topics:
http://osteele.com/posts/2008/05/my-git-workflow
This is where the canonical git explained image came from, but some of the topics here are somewhat advanced.
http://danielmiessler.com/study/git/
Quickly gets into some advanced topics – I think these diagrams are horrible, but the text is really good.
http://randyfay.com/content/rebase-workflow-git
No relation. This is the workflow I use. I always work in a local branch, then these series of commands basically integrate my work with whatever changes may have happened since I last did a push. git rebase is one of the most difficult things to understand and use effectively, and very easy to screw up.

This entry was posted in Dev, Uncategorized. Bookmark the permalink. Follow comments with the RSS feed for this post. Both comments and trackbacks are closed.