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/apache2I 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/apache2While the difference to the front-line working programmer is, in one sense, only a single command (
ln -s $WORKING_DIRECTORY /etc/apache2becomes 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.confand other artifacts have their natural home in a folder or directory called
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
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".
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.