Code, Camera, Action

Git is a great (and fashionable) source control management program. GitHub takes the pain out of hosting Git for a group — for both open-source and private projects. How to best use them together? The Way to Happiness has these 4 steps:

1. Fork the project on GitHub, and clone your version. This gives you your own copy to work with.
2. Make a branch (or frequent branches) for what you’re working on. Some folks systematize this with issue names and bug numbers — like “RedoPostFormatting-234” — which is probably a good idea for projects with lots of collaborators.
3. If you reserve certain branch names, like “master” and “staging” for production and pre-production code, you can merge a project’s code back into your tree more easily.
4. Or use the github-gem command line tool to grab a copy of somebody else’s code when needed. Here’s the salient snippet from the readme:

Let’s say you just forked `github-gem` on GitHub from defunkt.

$ github clone YOU/github-gem
$ cd github-gem
$ github pull defunkt

This will setup a remote and branch for defunkt’s repository at master. In this case, a ‘defunkt/master’ branch.

If defunkt makes some changes you want, simply `github pull defunkt`. This will leave you in the ‘defunkt/master’ branch after pulling changes from defunkt’s remote. After confirming that defunkt’s changes were what you wanted, run `git checkout master` and then `git merge defunkt/master` to merge defunkt’s changes into your own master branch.

Loading mentions Retweet

The folks at GitHub have taken the pain out of centralized Git hosting. Even better, they’ve built in tools that make distributed version control easy to use for group projects. But how to set up your repositories and branches to avoid merge pain? Here are two good options.

Making Merge Manageable

Setting up your Git repositories for open source projects at github has great tips for getting started — and for structuring your branches for group work. There are a couple of take-aways here:

1. Encourage contributors to track established branch names, like “master” and “edge”. At the office we use “master”, “staging” and “dev”.
2. This makes it much easier for developers to pull in changes from the official repository in a simple, fast-forward way
3. Develop on a separate branch (or branches). You might want to name that branch with your github id, to help folks keep it straight.

Michael also provides a solid how-to, so if “pull request” sounds weird to you, start here.

Another Way: Branch away and let github-gem straighten it out

The folks at GitHub have a Ruby command-line tool to manage this without the fancy branch naming conventions. You fork, and the tool helps keep everybody’s master branches separate. It also speeds merging from these masters.

See defunkt’s Github-gem for the code and a README that explains the tool’s awesomeness.

Github-gem assumes that master is where you’ll want to pull from. This matches what most folks do — unless they’ve benefited from the foresight of the Inoshi folks.

Whichever strategy you choose, Github’s network diagram is your visual to-do list. It shows who committed stuff that’s different than what’s on your branch. Say hello to the Network graph visualizer has the details.

Loading mentions Retweet

So you want to use Git for distributed version control. For Mac OS X 10.5 there are a couple of options for installing Git.

• Fink packages an almost up-to-date version, named simply git
• MacPorts packages an up-to-date version asgit-core

Either of these methods, though, installs lots of dependencies. Which requires lots of compile time. And lots of disk space — especially for the MacPorts version.

So I prefer to compile Git myself — and use Fink for dependencies. Here’s how I do it.

Install Fink by following Fink’s installation instructions.

fink install gettext-tools expat1-shlibs

From here the instructions in Git’s INSTALL file work just fine:

curl -O http://kernel.org/pub/software/scm/git/git-1.5.4.5.tar.gz
tar zxf git-1.5.4.5.tar.gz
cd git-1.5.4.5
make prefix=/usr/local all 
sudo make prefix=/usr/local install

Now for the manpages.

Rather than build the docs ourselves (which requires asciidoc and a host of dependencies), I prefer to download them precompiled from Git and manually copy them into /usr/local/share/man.

curl -O http://kernel.org/pub/software/scm/git/git-manpages-1.5.4.5.tar.gz
sudo tar zxf git-manpages-1.5.4.5.tar.gz  -C /usr/local/share/man

(Replace the version numbers here with what’s right for the version of Git you’re installing.)

Now we’re ready to try this out, we’ll ask what version we just installed, then show the manpage:

git --version
man git

Done. Happy versioning!

Update

Sean Santry has an even simpler way to avoid the gettext-tools dependency — by telling make that we don’t have msgfmt at all.

NO_MSGFMT=yes make prefix=/usr/local all
sudo make prefix=/usr/local install

Using this tip you can build Git without Fink altogether!

Comments on the Original Post

You can also just install a complete OS X package from http://code.google.com/p/git-osx-installer/. It’s only 3.6MB and spares you the manual install

Pieter de Bie 4 Apr 2008, 10:31 AM

Loading mentions Retweet

So you want to use Git the latest hotness in distributed version control. It builds easily using the instructions in the INSTALL file.

But on Centos 5 (or Red Hat Enterprise Linux 5) there are some dependencies to install first:

sudo apt-get install gettext-devel expat-devel curl-devel zlib-devel openssl-devel

From here the instructions in Git’s INSTALL file work just fine:

wget http://kernel.org/pub/software/scm/git/git-1.5.4.5.tar.gz
tar zxvf git-1.5.4.5.tar.gz
cd git-1.5.4.5
make prefix=/usr/local all 
sudo make prefix=/usr/local install

Now for the manpages.

Rather than build the docs ourselves (which requires asciidoc and a host of dependencies), I prefer to download them precompiled from Git and manually copy them into /usr/local/share/man.

wget http://kernel.org/pub/software/scm/git/git-manpages-1.5.4.5.tar.gz
cd /usr/local/share/man
sudo tar zxvf ~/git-manpages-1.5.4.5.tar.gz

(Replace the version numbers here with what’s right for the version of Git you’re installing.)

Now we’re ready to try this out, we’ll ask what version we just installed, then show the manpage:

git --version
man git

Done. Happy versioning!

Postscript

This would of course be easier of using rpm-build. If anybody has experience with a good RPM spec file for git — or using a Fedora Core src rpm — please let us know in the comments.

The good folks at Git also provide pre-compiled RPMs.

Loading mentions Retweet