has become the programming
world’s most popular version control system–at least
that’s what
surveys
conducted by Microsoft Corp.
suggest.
While there are abundant write-ups already available
for new users and administrators, from tutorials to
descriptions of clever merge workflows, I still
often encounter a few missteps
in basic version control naming and layout.
Cameron Laird is a vice
president with software consultancy
Phaseit, Inc., and
part-time
author concentrating on IT.
He has used and evaluated version-control systems
since before PCs. Follow Cameron on Twitter
as @Phaseit.
Here are a handful of tips you should know to make
the most of this
, and
its close relatives including
:
Choose your top-level name well. I often come across
Git projects set up in a way that I think creates
a minor but avoidable confusion. Suppose, for
instance, that a team decides to maintain configuration
files for a specific Apache service for a particular
client, ImportantCompany, within Git. The file
structure then looks something like
A new developer initializes her development instance
by performing
I prefer a layout along the lines of
Initialization then becomes
While the difference to the front-line working programmer
is, in one sense, only a single command (ln becomes
-s $WORKING_DIRECTORY /etc/apache2
unnecessary), my experience tells me that elimination
of the
symlink lowers the
“cognitive load” on programmers and simplifies
maintenance. I also think it’s healthy to make
it explicit that apache2.conf and
other artifacts have their natural home in a
folder or directory called apache2.
.../ImportantCompany/apache2.conf
.../ImportantCompany/mods-available/actions.conf
.../ImportantCompany/mods-available/actions.load
...
cd $WORKING_DIRECTORY
git clone https://$SERVER/ImportantCompany
ln -s $WORKING_DIRECTORY /etc/apache2
.../ImportantCompany/apache2/apache2.conf
.../ImportantCompany/apache2/mods-available/actions.conf
.../ImportantCompany/apache2/mods-available/actions.load
...
cd /etc
git clone https://$SERVER/ImportantCompany/apache2
Longer fully-qualified names in the Git repository vs.
a requirement to symlink into a host’s standard
configuration directories: which do you
find more natural and “self-documenting”?
Version control is more than source control
It was common with Git’s ancestors to talk about
“source code control”; for a variety of technical
and cultural reasons, some of the older-generation
tools didn’t handle binaries or certain other formats
well.
That’s really a thing of the past, though. When
you use Git today “for version control of files”,
as the Git home page advertises, control all
your project’s files: images, documentation,
associated presentations, pertinent database test
instances, build specifications, video-ed instructions,
and so on.
Like the point about naming above, the idea of
capturing everything isn’t specific to Git.
As Git’s popularity has exploded, however, it
seems that quite a few newcomers to version-control
have taken it up; some of them don’t yet understand
either how valuable it is to control non-text
artifacts, or that it is technically feasible.
Make your project “self-sufficient”: when someone
issues the command git clone $TOP_URL,
you should be confident that the clone includes
everything necessary, without having to pick up
miscellaneous pieces in separate operations.
Recent Git news
Google Code supports Git; that is,
Google Code
has, since mid-July 2011, acted as a server
which fully honors Git client requests. You can combine the
advantages of Google Code and Git.
The Google Code announcement reinforces that
Git is possible without GitHub. The GitHub public site
certainly deserves the popularity and traffic it has
attracted. Sometimes beginners with Git don’t appear
to realize, though, that there are alternatives to
GitHub: not only can an organization set up its
own Git server, but public sites like Google Code
are right for some teams.
At a lower level, several commands allow for combinations
of functionality from Git and other tools.
git-svn, for example,
makes it possible for users to get
the client functionality of Git
while working against a Subversion repository.
If you or your team are making a transition between
different technologies, look into such “bridges”.
Recognize that Git isn’t for everyone; there are
good reasons to favor
Launchpad over Github, for instance (also see
this,
this,
this), or
Mercurial over Git (also see
this).
As with so many important matters, perhaps what matters most
in version control systems is balance: version control is
only a tool, not a goal in itself. On the other hand, expertise
in the tool can multiply your effectiveness with the code that
presumably is your focus. Study more about version control and
what it can do for you through such good write-ups as, for
example, Eric Sink’s website.
