I wanted to try out git on the Mac. I'm reading the book Pragmatic Version Control Using Git by Travis Swicegood. There's a forum discussing this book on the Pragmatic Programmer's site, http://forums.pragprog.com/forums/64. The forum seems to be more focused on reviewing the book than discussing git issues, however.

Installing and Configuring

I have a Mac Book Pro (Intel) with Snow Leopard. To get MacPorts I went to the site http://www.macports.org/install.php and clicked on Snow Leopard.

Once MacPorts is installed, I issued the command

newtricks:~ ted$ sudo port install git-core +svn +doc

There's a Pragmatic Programmer forum entry that discusses how this macport installation of git did not work, but it worked fine for me. I can tell git is installed and working by checking its version.

newtricks:~ ted$ which git
/opt/local/bin/git
newtricks:~ ted$ git --version
git version 1.6.5.7
newtricks:~ ted$

There are only two required configuration values: user.email and user.name. Here's how you set them; they are silent commands.

git config --global user.name "Ted Kubaska"
git config --global user.email "ted.kubaska@gmail.com"

Although not required, the configuration value color.ui is useful. It color codes various git output. I'll show some examples later.

Display the configuration as follows.

newtricks:~ ted$ git config --global --list
user.name=Ted Kubaska
user.email=ted.kubaska@gmail.com
color.ui=auto
newtricks:~ ted$

Creating a Git Repository

Creating a git repository is pretty easy, in fact trivial. Just make a directory, enter it, and issue a git init. Then you can add files into this repository with git commit. This directory will be the working tree of code you check out from the repository. The repository metadata is in the directory/.git, and, guess what, its contents don't look like CVS.

So I do this ...

newtricks:GitRepo ted$ mkdir tedsrepo
newtricks:GitRepo ted$ cd tedsrepo/
newtricks:tedsrepo ted$ git init
Initialized empty Git repository in /Users/ted/GitRepo/tedsrepo/.git/
newtricks:tedsrepo ted$ ls -a
. .. .git
newtricks:tedsrepo ted$ pwd
/Users/ted/GitRepo/tedsrepo
newtricks:tedsrepo ted$

Then, in that directory, make a file (call it hello.html) to add to the repository.

newtricks:tedsrepo ted$ git add hello.html
newtricks:tedsrepo ted$ git commit -m "Initial checkin for hello.html"
[master (root-commit) f2c49ba] Initial checkin for hello.html
1 files changed, 6 insertions(+), 0 deletions(-)
create mode 100644 hello.html
newtricks:tedsrepo ted$ git log
commit f2c49baf3abafefb03b941db75ae4c026b0c877e
Author: Ted Kubaska <ted.kubaska@gmail.com>
Date: Tue Dec 29 21:07:15 2009 -0800

Initial checkin for hello.html
newtricks:tedsrepo ted$

Make a change in hello.html. Before you can commit the changed file, you must stage it. This is something that seems unique to git. You edit a file, and then you can't just commit it ... you must stage it first.

newtricks:tedsrepo ted$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: hello.html
#

no changes added to commit (use "git add" and/or "git commit -a")
newtricks:tedsrepo ted$

Notice that a modified, but unstaged file is shown in red. This is a result of that color.ui configuration value.

So stage the file before committing. Stage with git add. Note that the filename becomes green.

newtricks:tedsrepo ted$ git add hello.html
newtricks:tedsrepo ted$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: hello.html
#
newtricks:tedsrepo ted$

Then, commit.

newtricks:tedsrepo ted$ git commit -m "added head and title"
[master 4b7d2f1] added head and title
1 files changed, 3 insertions(+), 0 deletions(-)
newtricks:tedsrepo ted$

Branches

With CVS, I've always been very careful not to proliferate branches. But I think (from what I've read so far) that branches are key to the way people use git.

The name of the default branch in git (the branch you start with, the mainline, if you will) is called master. Master in Git is what I would call HEAD in CVS.

I thought it was interesting that you can create a branch, checkout the branch, edit a file and commit it to the branch. Then, checkout the master and edit and commit. You now have one version of the file in the branch and another in the master. Now if I rebase the master, the file in master has the changes that were made in the branch as well as the changes made on master. This sounds like a merge to me, although it's not technically a merge because there is a merge command. I suppose I'll see the difference when I start using the merge commands.

Here's what I mean in more detail. The following figure illustrates the actions I'm describing.

Let's say I'm on the master branch of my git repository. I put three lines in that file. I commit the file, then make a branch called R1.0. I edit the file again while still on master (the file now has four lines) and commit it.

Master line 1
Master line 2
Master line 3
Master line 4 <-- this is the line I added on master (not the branch)

Then, I checkout the branch and edit/commit the file.

Master line 1
Release line 1 <-- this is the line I added on the branch (not master)
Master line 2
Master line 3

Then, I checkout the master and rebase master with the branch. My file now has the changes from both the branch and master.

Master line 1
Release line 1
Master line 2
Master line 3
Master line 4

Here's the output I got from the rebase command.

newtricks:tedsrepo ted$ git rebase R1.0
First, rewinding head to replay your work on top of it...
Applying: added 4th master line
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging hello.txt
newtricks:tedsrepo ted$ git branch -d R1.0
Deleted branch R1.0 (was f3a999b).

As I said, it looks like a merge to me, but I've more to learn.

What is also interesting is that (with the branch checked out), you can tag it. Then, you can checkout master, rebase master with the branch, and actually delete the branch. You can restore the branch by make a new branch from the tag, like ...

newtricks:tedsrepo ted$ git branch R1.0 1.0

where 1.0 is the tag. I made the tag when the branch (called R1.0) was checked out as

newtricks:tedsrepo ted$ git tag 1.0 R1.0