New jobs always come with learning "opportunities"; this one was no
different in that respect. Once this long-time vi bigot learned enough
emacs to create a daily security update, the big learning challenge was Git. I have used many different revision
control systems along the way, starting with sccs, through RCS and CVS, to
subversion – and a dash of mercurial. Git is fundamentally different
than all of those – though mercurial is close – its learning curve
is steep, its usage model is radically different.
One of the major differences is that Git is a distributed revision (or
version) control system, while most of the others are centralized. In a
distributed system there is no central repository that everyone uses to put
their changes into, there are, instead, numerous repositories, each
residing on a developer's machine. Typically, those developer repositories
have been "cloned" from a master repository somewhere. Each developer then
owns their repository; they can make changes, commit them, make branches,
tag releases, etc. – all without ever contacting the master
repository. When they are ready to share their changes, they either "push"
them into a repository, or, more likely, ask a repository owner to
"pull" changes from a specific branch of their repository.
Another reason for the steep learning curve is that Git started out as a
fairly low-level tool, just providing the
"plumbing" for version control. The intent was to add more user-friendly
interfaces to the plumbing, so-called porcelain, as time went on. As Git
matured, the porcelain has moved in with the plumbing, so the core Git package
has had many of the rough edges filed off, but it is still lower-level than
most other revision control systems. In my Git learning journey, I found
a number of helpful sites, that can help get users up to speed rather quickly.
For users who want to learn Git so they can look at Linux kernel
source, the best starting point is Jeff Garzik's "The Kernel Hackers' Guide to
Git". It provides a quick overview of the commands needed to grab a
copy of Linus's kernel tree, make branches from it, commit to it, and keep
it up to date. The main missing
piece is on using tags, which is how different versions of the kernel are
represented in the repository.
If managing a project with Git is in the cards, the right starting point
is: "A tutorial
introduction to git". This covers the basics of setting up a
repository to hold a project and importing the project's code. It also has
sections on many of the tasks that a repository user will need to commit
their changes, create branches for parallel lines of development, follow
the history of changes, and collaborate with others. The second part
of the tutorial covers some of the internal workings of Git: the object
database and the index file.
Those coming to Git from another version control system may want to look at
the tutorials specific to their tool. CVS and subversion have their
own tutorials, each geared towards users converting from those centralized
version control systems. The "git
for CVS users" page is a bit terse, often referring to the tutorial
above, but it does provide some of the basics a CVS user will need. The
"Git - SVN Crash Course" on
the other hand is fairly in-depth coverage, presenting the exact Git
equivalents for a large number of svn commands and concepts.
Once the basics have been mastered, it is time for the serious reference
material, which is where the Git
User's Manual comes into play. It contains multiple chapters covering
every facet of Git, including a detailed look at the internals of Git, its
storage formats and the like.
When trying to do something more complicated than is covered in the
narrowly focused tutorials, the User's Manual is the place to go.
Git commands are typically invoked from the command line as subcommands of
the git command: git commit for example. When trying to track
down the most serious reference material of all, though, using an alternate
syntax to refer to the Git subcommands is required: man git-commit
for example. From the command line, man
git is a good starting point; the same information, with nice clicky
links, is also available here.
With these reference materials at hand, it should be fairly straightforward
to get up and running with Git. For me, at least, there is still a lot to
learn, but with these sites available, I am mastering more of it each time
I dive in. If still more information is needed, the GitWiki and its documentation page are
the next places to try.
to post comments)