Git

Ideally, you could refer the whole world --- or at least, the significant portion thereof that want your code --- to your (public mirror) Git repository. But unfortunately, the whole world does not (yet) use Git ("I know it was you Fredo, I know it was you, and it breaks my heart."). Sad. Sooooo sad. But true. So the only recourse is for you to send these tortured souls an archived snapshot of your code via e-mail. I'll pause now to let you finish retching/sobbing/lamenting/venting. ... Back? Anyway, Git has a neat "archive" command that helps you create the required archive, but perhaps it does not have the most friendliest interface in the world. Drop the following script anywhere on your path name it "git-targz" and set its executable bit on. Then invoking "git targz TARBALL-FILEPATH" will create a tar'd and gzip'd bundle of your (repository's) current HEAD. Similar scripts for bzip'ing and plain old zipping can easily be created by varying the final command, and are shown after the tar + gzip script.

Part 1 of this article described a standard development workflow using Git that took advantage of the distributed nature of the system to maintain a code base across two or three different repositories, including a primary shared "working" code repository and a development "work-in-progress" code repository. Some aspects of this workflow are tedious and reptititive, while others, such as the management of different branches in different repositories can make housekeeping a little more complex. In this, the second part of the two-part series, I present a few simple scripts or tools that, when incorporated into the development ecosystem, go such a long way in alleviating these problems that the whole process quickly becomes a seamless and natural part of the standard routine.

Repository Setup

For most major projects, I have at least two, and sometimes three, remote Git repositories upstream of my local one:

With multiple upstream repositories and branches, and different branches on different upstreams, an enhanced "log" view will help greatly in taking stock of everything.

When you pull and update your local, it would be nice to easily see all the commits that you have applied in the pull. Sure you can figure it by scanning through the git log carefully, but adding the following to your '~/.gitconfig' gives you an easy way to see it in a glance:

The following will enable you to have a Git-aware "cd" command with directory path expansion/auto-completion relative to the repository root. You will have to source it into your "~/.bashrc" file, after which invoking "gcd" from the shell will allow you specify directory paths relative to the root of your Git repository no matter where you are within the working tree.

Here are three confessions:

This OS X Dashboard Widget displays a "cheat sheet" style summary of selection of Git commands that are commonly used in most development workflows:

You can download it from here:

Deleting a local tag is straightforward, and uses the "git tag":

# git tag -d v.7b

Deleting a remote tag is the same syntax and idiom (and, in fact, command) as deleting a remote branch:

# git push origin :v.7b