cat brain.log | less

Getting it down on `paper`

Git – Install and Configure

Git is a code revision system not much unlike subversion and CVS.  One of the best features of git is that it is a distributed revision system, so you can check-in, check-out, commit, revert, etc without ever needing direct access to the central repository.  You can work with your repository as if it were a centralized system if need be found.

Installation (from source)

Go to and pick the latest version (, then from the command line, issue:

# Make a temporary directory from which we'll work
mkdir ~/gittmp
cd ~/gittmp

# Get the source, compile and intsall
tar xzf git-
cd ~/gittmp/git-
sudo make install
cd ~/gittmp

# Get and install the man pages
sudo tar xzf git-manpages- -C /usr/local/share/man/
cd ~
rm -r ~/gittmp/


Now that we’ve got everything set up, go ahead and check that everything’s visible to your path.  Note: You may need to log back in for the settings to be read.
$ which git
$ git config --help
--- man page retrieved ---


Now we need to set some globals. These are used to identify you when pushing changes.
$ git config --global "Scott Chacon"
$ git config --global ""

In a distributed environment, your workflow might go something like: A writes some code and commits. B pulls code, makes updates, commits. A updates local copy with B’s committed changes, continues development. The flow goes: get updates from peer, make changes, commit. Here’s an example:
alice: $ cd ~/project
alice: $ git init
alice: $ git add lib src README CHANGELOG
alice: $ git commit -m "Initialization"
bob: $ git clone /home/alice/project myrepo
bob: $ echo 'I made a change' >> CHANGELOG
bob: $ git commit -a -m "Appended changelog info"
alice: $ cd ~/project
alice: $ git pull /home/bob/myrepo master
alice: $ echo "Confirmed, changes were merged" >> CHANGELOG
alice: $ git commit -a -m "Merged bob's changes with some new additions"

Another setup might be to have a public repository for centralized access. It’s not really a central repository, but it’s the place where you push all your changes to from any machine you work on. In this way, anyone can go to exactly one place to get changes you’ve made, and you can work from any machine with git, using your own public repository as a starting point.
$ git clone --bare ~/proj proj.git
$ touch proj.git/git-daemon-export-ok
$ scp -r /proj.git

Want to have access to the repo via http? Try this:
$ mv proj.git /var/www/html/repos/proj.git
$ cd /var/www/html/repos/proj.git
$ git --bare update-server-info
$ chmod a+x hooks/post-update

Now anyone can access your repository like so: $ git clone

Prefer a private repository? It’s easier than the public setup.
You: $ git clone --bare /home/user/myrepo/.git /tmp/myrepo.git
$ scp -r /tmp/myrepo.git

Peer: $ git clone

So how do these shared repositories work?

  1. clone to initialize local git revision management
  2. modify/commit/revert/etc locally (1 or more times)
  3. push up to the shared repository

Peer: … makes changes to source …
Peer: $ git commit -a -m "I made a few changes"
Peer: … continue editing until ready for consumption …
Peer: $ git commit -a -m "I made a few more changes"
Peer: $ git push ssh:// master[:master]
You: $ git clone
You: … editing/conflict management/etc. …
You: $ git commit -a -m "Pretty up peer's changes (minor edits)"
You: $ git push ssh:// master[:master]

Using Git on Windows

If you plan on using Git on Windows (Sure, why not? masochists pssht) you could install Git Extensions (Windows) from At least, that’s what I did. It was confusing as all hell, until I went through all possible alternatives that appeared easier than understanding what a remote is. The key to getting it all to work is setting up ssh keys so that you can auto-logon to whatever server has your git repositories with the ssh protocol. If you’re using the git protocol, I don’t think that applies. I could be wrong on this.

Once you’ve installed Git Extensions, load it up, do some general configuration (,, etc.), then select from the menu bar Remotes->PuTTy->Generate or import key. This assumes that you’ll be using PuTTY for all your ssh needs (if applicable). Anyway, generate a key and save the public key somewhere handy, save the private key somewhere safe. Now, using that pubkey, follow the advice for Setting up SSH Keys. You’re going to want to add that pub key to your authorized_keys on the git repo server. After that, make sure the PuTTY authentication agent is running (Remotes->PuTTy->Start authentication agent). A new icon should appear in your system tray. Right click on the new icon to “Add Key.” This key will be your private key. The agent handles the hand-shaking.

After doing all this the hard way, maybe you should just use the git protocol, but then again, I haven’t tried it myself.


Finally, it’s probably best to read Git’s HOWTOs and Tutorials.



No comments so far.

(comments are closed)