ReadWrite - Cameron Lairdhttp://readwrite.com/author/cameron-laird
enCopyright 2015 Wearable World Inc.http://blogs.law.harvard.edu/tech/rssTue, 03 Mar 2015 10:47:19 -0800How to Get the Most out of Git<!-- tml-version="2" --><div tml-image="ci01b2996fb0018266"><figure><img src="http://a5.files.readwrite.com/image/upload/c_fill,cs_srgb,w_620/MTIyMzI4ODQzNzkxOTg1OTQ1.png" /></figure></div><p><a href="http://git-scm.com/">Git</a></p><p> has become the programming
world's most popular version control system--at least
that's what
</p><p><a href="http://www.itproportal.com/2011/07/20/microsoft-survey-reveals-github-git-most-popular-among-developers/">surveys
conducted by Microsoft Corp.</a></p><p> 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.
</p><blockquote tml-render-size="large"><p><em><a href="http://phaseit.net/claird">Cameron Laird</a> is a vice
president with software consultancy
<a href="http://phaseit.net">Phaseit, Inc.</a>, and
part-time
<a href="ttp://phaseit.net/claird/misc.writing/publications.html#computer_article">author concentrating on IT</a>.
He has used and evaluated version-control systems
since before PCs. Follow Cameron on Twitter
as <a href="http://twitter.com/@Phaseit">@Phaseit</a>.</em></p></blockquote><p>
Here are a handful of tips you should know to make
the most of this
</p><p><a href="http://whygitisbetterthanx.com/">successful open-source tool</a></p><p>, and
its close relatives including
</p><p><a href="http://subversion.apache.org/">Subversion</a></p><p>:
</p><p>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 (<code>ln
-s $WORKING_DIRECTORY /etc/apache2</code> becomes
unnecessary), my experience tells me that elimination
of the
<a href="http://en.wikipedia.org/wiki/Symbolic_link">symlink</a> lowers the
"cognitive load" on programmers and simplifies
maintenance. I also think it's healthy to make
it explicit that <code>apache2.conf</code> and
other artifacts have their natural home in a
folder or directory called <code>apache2</code>.
</p><pre>
.../ImportantCompany/apache2.conf
.../ImportantCompany/mods-available/actions.conf
.../ImportantCompany/mods-available/actions.load
...
</pre><pre>
cd $WORKING_DIRECTORY
git clone https://$SERVER/ImportantCompany
ln -s $WORKING_DIRECTORY /etc/apache2
</pre><pre>
.../ImportantCompany/apache2/apache2.conf
.../ImportantCompany/apache2/mods-available/actions.conf
.../ImportantCompany/apache2/mods-available/actions.load
...
</pre><pre>
cd /etc
git clone https://$SERVER/ImportantCompany/apache2
</pre><p>Longer fully-qualified names in the Git repository vs.
a requirement to symlink into a host's standard
configuration directories: which do <em>you</em>
find more natural and "self-documenting"?
</p><h2>Version control is more than source control</h2><p>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.
</p><p>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 <strong>all</strong>
your project's files: images, documentation,
associated presentations, pertinent database test
instances, build specifications, video-ed instructions,
and so on.
</p><p>Like the point about naming above, the idea of
capturing <strong>everything</strong> 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 <code>git clone $TOP_URL</code>,
you should be confident that the clone includes
everything necessary, without having to pick up
miscellaneous pieces in separate operations.
</p><h2>Recent Git news</h2><p><a href="http://code.google.com/p/support/issues/detail?id=2454">Google Code supports Git</a>; that is,
<a href="http://code.google.com">Google Code</a>
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.
</p><p>The Google Code announcement reinforces that
Git is possible without <a href="http://github.org">GitHub</a>. 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.
</p><p>At a lower level, several commands allow for combinations
of functionality from Git and other tools.
<code>git-svn</code>, for example,
makes it possible for users to get
<a href="http://durdn.com/blog/2011/07/06/using-git-with-subversion-tips-that-will-make-your-life-easier/">the client functionality of Git
while working against a Subversion repository</a>.
If you or your team are making a transition between
different technologies, look into such "bridges".
</p><p>Recognize that Git isn't for everyone; there are
<a href="http://www.slideshare.net/sidnei/10-razoesparausarlaunchpad-8503043">good reasons to favor
Launchpad over Github</a>, for instance (also see
<a href=" http://paul-classic.stadig.name/2008/06/23/launchpad-vs-github/">this</a>,
<a href="http://sheddingbikes.com/posts/1299555462.html">this</a>,
<a href="http://andymatuschak.org/articles/2008/05/07/more-on-launchpad-bazaar-vs-lighthouse-github/">this</a>), or
<a href="http://www.wikivs.com/wiki/Git_vs_Mercurial">Mercurial over Git</a> (also see
<a href="http://stackoverflow.com/questions/35837/what-is-the-difference-between-mercurial-and-git">this</a>).
</p><p>As with so many important matters, perhaps what matters most
in version control systems is <em>balance</em>: 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, <a href="http://www.ericsink.com/scm/source_control.html">Eric Sink's website</a>.
</p>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…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-gitHackThu, 21 Jul 2011 23:00:00 -0700Cameron Laird