Cameron Laird - ReadWrite http://readwrite.com en Copyright 2012 SAY Media, Inc. readwriteweb@gmail.com http://blogs.law.harvard.edu/tech/rss Thu, 21 Jul 2011 23:00:00 -0700 <![CDATA[How to Get the Most out of Git]]> Git 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 successful open-source tool, and its close relatives including Subversion:

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 

      .../ImportantCompany/apache2.conf
      .../ImportantCompany/mods-available/actions.conf
      .../ImportantCompany/mods-available/actions.load
	    ...
A new developer initializes her development instance by performing 
       cd $WORKING_DIRECTORY
       git clone https://$SERVER/ImportantCompany
       ln -s $WORKING_DIRECTORY /etc/apache2
I prefer a layout along the lines of 
      .../ImportantCompany/apache2/apache2.conf
      .../ImportantCompany/apache2/mods-available/actions.conf
      .../ImportantCompany/apache2/mods-available/actions.load
	    ...
Initialization then becomes 
       cd /etc
       git clone https://$SERVER/ImportantCompany/apache2
While the difference to the front-line working programmer is, in one sense, only a single command (ln -s $WORKING_DIRECTORY /etc/apache2 becomes 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.

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. ]]> http://readwrite.com/2011/07/21/how-to-get-the-most-out-of-git http://readwrite.com/2011/07/21/how-to-get-the-most-out-of-git Analysis Thu, 21 Jul 2011 23:00:00 -0700 Cameron Laird