As I worked through this website (which is great by the way) it struck me that by focusing so clearly and completely on the underlying object graph that's supposed to lead to nirvana for learners, the site does a great job of highlighting the obtuseness of Git's command set.
I mean you've got a great honking big graph on the screen, another big honking graph to the side, and you're asked to "make this one look like that one". This should be so easy now that you see it - essentially drag and drop albeit with text commands - it should have almost no pedagogical value (if you built a model in Lego then it would literally be child's play). Yet even having identified what I needed to move and where I wanted to move it, the challenge remained - what is the weirdly named command I must type to make that (and only that) happen? Which way round are the arguments again? (eg. 'git rebase', to move stuff from the current branch to somewhere else, versus 'git merge', to 'move' stuff from somewhere else to the current branch, always gives me pause.)
I'm most grateful to this website for telling me about 'git branch -f <branch name> <destination>' as a way to repoint a ref. To think that all this time I thought you had to checkout the ref, reset --soft, then maybe checkout again if you wanted to get HEAD back to where it started (all the while dealing with the side effects and possible conflicts with your working directory). None of the tutorials or books I had read, such as "git for computer scientists", "Think Like a Git", or the "Pro Git" book ever mentioned (correct me if I'm wrong) that fairly fundamental operation despite schooling me quite thoroughly in the "think of the object graph" mindset. (Yeah it's in the man page, but then there's a lot of stuff in the manpage so noticing it is the problem there. And I tend to assume any option named "--force" is something that I shouldn't be messing with. Why not "git repoint-ref" or "git move-ref" anyway? Git has so many top-level commands already, it doesn't seem like they're worried about polluting that namespace.)
But, if the people involved are proficient using it and the learning is not a issue, there is still git goodness to be used (or even dare I to say: to enjoy).
I find myself using A LOT of local branches while developing. Not only they are cheap to make/destroy, it's pretty flexible to manipulate it (ya, rebase).
When you are comfortable with things like staging, stashing, branching, rebasing, rebasing interactively, using -p (patch) in commands and reflog git enables you wonderful workflows (note the plural).
There is this gap between awkardness/frustation and power/enjoyment when using git. Tools like these help people jump it.
I strongly disagree. All my projects use git and the majority of them are small with a central repository.
As someone who learned Git and SVN at the same time, I think git has an undeservedly bad reputation. There are many workflows where Git is much easier to grasp conceptually (initializing a new repo, branching, how do I work on an airplane?) I think people who are comfortable with SVN tend to forget that, other than the confusion around staging, it's easier for rank beginners to learn the basics of Git than the basics of SVN.
(Just now I am converting some scientific collaborators to use Mercurial for small projects. Still, for code I use Git... but mainly because of GitHub.)
It's like power tools for my code.
Until a better way comes along, we still mostly develop software with code in a bunch of files. And we still mostly depend on the shitty filesystem for all that. That's what Git does. Frees me to some extent from the shitty filesystem.
Personally I think Git is always useful but I reap far, far more dividends on big projects where the forking, branching and merging give me support for software engineering as the social craft that it is.
- It is an overkill for a small project with a central repository - what we usually have, leading to a large conceptual overhead.
Why it became popular in the first place? a) Linus, b) It's pretty easy and pain-free when you have a single-person project that doesn't branch much.