Re: Why is it important to learn git?

[Dmitry Potapov <dpotapov@gmail.com>]

On Tue, Jul 21, 2009 at 11:08:31PM -0600, Tim Harper wrote:
> 
> How has mastering the advanced features of git helped you to be a
> better programmer?

I don't think that features itself make as big difference as the fact
Git provides you much more flexibility in choosing a more appropriate
workflow than you have with any centralized VCS. (Yes, you will still
find many Git features handy even if you work with it as you did with
CVS, but you will miss most benefits of Git).

To really understand what benefits Git offers, you have to realize first
what is wrong CVS and CVS-like VCSes. Unfortunately, it is difficult to
explain just in a few words. Some implementation deficiency of CVS is
obvious (and it was addressed in some CVS clones like Subversion), but
more fundamental problems are far less obvious even for people who used
CVS for many years.

To be fair to CVS, it is far from the worst VCS. There are some insane
lock-based VCS, which were so painful to use (mostly due to these
exclusive locks but often due to some other insanity too) that anyone
who worked with may think about CVS as a really nice system...

In some way, CVS was really revolutionary for its time, because it used
the copy-modify-merge paradigm instead of excluding locking, which was
dominant before the CVS era. Those exclusive locks not only could not
work over the Internet, they were so excruciatingly annoying even if
everyone was sitting in the same room... Despite some initial skepticism
about essentially the lock-free VCS, I think it is safe to say now that
the copy-modify-merge paradigm won. Period.

However, if you look at the support of this paradigm in CVS and other
centralized VCSes, it is very limited in every aspect:
- copy: you can have a copy only one revision. (it may not be a big
  issue unless you like to work offline and to look at history).
- modify: there is no problem with modification itself, but you cannot
  save your changes without committing that to the official repo, which
  is not such a good thing if they are not ready yet or were not reviewed
  properly.
- merge: well.. I don't think there is any sane person who enjoyed
  merging branches in CVS... The only merge that was _relatively_ easy
  to do was merging your worktree with the upstream. Even that is not
  perfect in CVS, because you cannot save your changes before merge. So,
  if you made a mistake during 'cvs update', you risk to losing your
  work... Also, there is no possibility to review the merge later or to
  delegate to someone else when its resolution happens to be tricky...

The above limitations have further consequences with negatively affect
co-operation among developers. For instance, it is very difficult to
organize the review process with any centralized VCS. Typically, a
review process may require saving and share your work with reviewer
without committing it to the central repo. Also, this work should be
split into logical steps to make review easier. The only way to do that
with a centralized VCS is to use some patch management system on top of
it.... and at that point you may ask whether you want to learn two
systems with overlapping functionality and not so well integrated with
each other?

Another important reason why feature branches are so useful is that they
allow to postpone the decision about integration of some feature to the
master branch to the time when you convince that it is ready and useful.
In a "centralized" workflow, people often commit as they progress to
their goal, but some ideas may not so good as they initially appeared.
At the time when you realize that, your changes already intervened with
other people changes. There is no easy way to remove them cleanly. And,
some work even if it is useful may be not ready to the time when you
planned to realize a new version. This results in unnecessary delays in
release.

There are more problems with the "centralized" workflow used by CVS and
alike. They may be not very noticeable on small projects, but it tends
to get worse as any project growths over time.


So, the main advantage of Git is not in the number of features (and Git
has plenty of them despite of efforts to limit them to only truly useful
for many users), but its conceptual wholeness and flexibility, which
allows you to choose the appropriate workflow for your needs.


Dmitry