Why is it important to learn git?

Hi all,

I'm preparing to teach a workshop on git, and would like to know how other people benefit from the advanced features of git. So, if you're feeling kind enough to share a few minutes to respond (which I will receive with gratitude):

How has mastering the advanced features of git helped you to be a better programmer?

Tim Harper wrote:

I came from SVN, and I guess the most important change for me was:

  Learning to make nice, reviewable, working, one-change-per-revision
  commits.

This must be enforced by social pressure of course, but 'add --patch', 'commit --amend', 'rebase --interactive' and some others make it very easy to actually do it even when working on a series of changes.

Heya,

On Wed, Jul 22, 2009 at 07:52, Thomas Rast<trast@student.ethz.ch> wrote:

I very much agree with those values, but also

  Commit early, commit often

It's very convenient to be able to go back to/diff with a previous version later on, running 'git commit -am "got x half-working"' takes only a few seconds, but can save hours later on when you got x totally-not-working-at-all-anymore.

Sverre Rabbelier <srabbelier@gmail.com> writes:

 
I also find commit message convention: "short one-line description,
separated by empty line, then more detailed description" to be very
useful (git tools assume and expect this convention).  It helps
keeping changesets / commits small; if you can't write oneline summary
of commit, it is probably too large :-)

On Wed, Jul 22, 2009 at 09:52:26AM +0200, Thomas Rast wrote:

Same here. Git makes this easy to do. But it also makes me _want_ to do it, because I benefit later from the advanced history investigation tools like bisecting, pickaxe, blame, and even just decent visualization like gitk that is lacking in other systems.

And of course if your workflow is based on reviewing patches (like for git itself), then it is almost necessary.

-Peff

Thomas Rast wrote:

Seconded. During the CVS days, noone bothered about history, but with git a it's a veritable goldmine of important information, so it's important to keep it clean with minimal changesets.

One of our developers was very sloppy about this until he ended up with a bisection run landing him on a commit that fixed no less than seven different issues. He spent four days debugging it and finally had to resort to breaking the issues up and creating the commits as they should have been on a temporary side-branch and then bisecting that side-branch. Having done that, he spotted the error in about 15 minutes. After some swearing, he finally saw the light. He's actually a happier person now, since bugs that take a long time to solve upset him quite enormously and now he never runs into any :-)

Apart from that, the various ways of cooperating over large distances (easy branching + merging, patch sending/applying utilities) are a huge benefit for us.

Hey,

On Tue, Jul 21, 2009 at 10:08 PM, Tim Harper<timcharper@gmail.com> wrote:

I think the biggest gain Git gives many developers over other VCSs (even other DVCSs) is the lightweight branching flexibility and easy merging. In Git, lightweight branches or topic branches are used in much the same way that patch queuing tools like Hg's mq extension or quilt, but I think most users find them much, much easier to use and understand and often less error prone. Using branches as silos dedicated to a single work topic and being able to easily keep them separated until you are ready to apply them to a main line of work (such as merging with your master branch) is very powerful and is done via a very simple and understandable existing paradigm of branches rather than trying to learn a whole new command set of patching. This allows for fast and simple context switching and work unit isolation that both very definitively changes most developers workflows in ways that were completely impossible in SVN or Perforce or what-have-you.

Hope that helps. If you need any material for your workshop, I have a number of slides (Keynote and PDF) for presentations I have given at:

http://github.com/schacon/git-presentations

You can also get the PDF of the slides of the tutorial I gave at OSCON yesterday on Git here:

http://en.oreilly.com/oscon2009/public/schedule/detail/7953

Let me know if there is anything else I can do to help.

Thanks, Scott

On Tue, Jul 21, 2009 at 11:08:31PM -0600, Tim Harper wrote:

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

Dmitry Potapov <dpotapov@gmail.com> writes:

See also my answer for "Difference between GIT and CVS" question at StackOverflow:

  http://stackoverflow.com/questions/802573/difference-between-git-and-cvs/824241#824241
 

By the way, even if CVS didn't implement support for file renames and copying, at least it provides support for file deletion (as opposed to *khem* SourceSafe).

Has anyone done a presentation on this (very interesting) subject with examples?

What's good about this practice/pattern? What's bad about that practice/pattern?

I ask because if not, I'd like to - with your help!

Cheers, al.

2009/7/22 Jakub Narebski <jnareb@gmail.com>: