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.
I recently integrated unit test code coverage analysis (using coverage) as a setuptools command extension into the DendroPy phylogenetic computing library, and thought that I would share how this was done.
The following is an example of how to use the "pkg_resources" module (provided by the setuptools project) to compose a list of all available modules in a Python package.
Here are three confessions:
This OS X Dashboard Widget displays a "cheat sheet" style summary of selection of Emacs commands:
You can download it from here:
One of the great strengths of Git is the multiple and flexible ways of handling remote repositories. Just like Subversion, they can be "served" out of a location, but more generally, if you can reach it from your computer through any number of ways (ssh, etc.), you can git it.
YonderGit wraps up a number of a common operations with remote repositories: creating, initializing, adding to (associating with) the local repository, removing, etc.
You can clone your own copy of the YonderGit code repository using:
feed