
Git Immersion - tortilla
http://gitimmersion.com/
======
roel_v
I've tried several times over the past couple of months to read articles or
introductions to git. The one thing they seem to have in common is that it
looks like they're having a contest on who can come up with the most
outrageous ways of saying how bad other version control systems are. Anyway so
I read through this whole website, but again this one fails to say: what does
git do that others can't? Specifically, what is better about git than
Subversion? There's the 'distributed' aspect which in some specific scenarios
is nice. There seem to be some niceties like adding files to a commit one by
one and doing a 'final' commit only at the end; that's a pain to do with the
commandline subversion client (but it's really easy with Tortoisesvn).

So, is there a concise explanation somewhere of what makes git better than
subversion?

~~~
kgrin
Branching works. I know it works in theory in SVN, but in practice one often
runs into problems with any non-trivial branch. With git (or really DVCS),
branching typically Just Works.

~~~
roel_v
What are those problems? Why are they less with git? I often make branches
with subversion; what goes wrong is keeping track of what features/changesets
need to be merged across which branches, plus 'dependencies' of those
changesets (changes in previous commits to the branch that add e.g. a class
definition that the changesets depends on). Does git improve on that? How?

~~~
shadowmatter
What he really means is that branches are now a part of your daily workflow.
You can sync up to head (or wherever you pulled your working copy of the
repository from), create a branch, and start working on some feature on that
branch, mucking up a hundred files along the way. Now say some some urgent
issue comes up that you need to fix immediately -- you can easily go back to
the point before you branched, and create a new branch from there on which you
can fix the issue. Meanwhile, your previous branch still exists, so when the
urgent issue is fixed you can resume where you are working on. Another great
thing about branches is say you're working on some feature in a branch and you
come to a point where you can implement something multiple ways, but don't
know which one will turn out elegant. You can create a new branch from that
point in your current branch, and if it doesn't pan out, revert it to where
you were.

The kicker with Git is that all these branch operations take on the order of
milliseconds because Git stores the entire project history -- all past
revisions of files, etc -- locally. Sure, you pay in a bit of disk space, but
consequently almost all common operations can be done without hitting the
network and are crazy fast. Even when you execute a commit, you're not
committing to a server, but to your working copy of the repository. Later, you
can push your changes somewhere else and merge accordingly.

~~~
beagle3
Furthermore, git stores the entire project history locally and compressed in
such a way that a live git project (checkout+entire history) often takes LESS
space than an equivalent live subversion project (checkout * 2, which
subversion does for allowing you to diff without having to go to the server).

Obviously, if you add a 1GB random file then delete it, the git entire history
will have 1GB more data than an SVN checkout. but usually, it's smaller.

I've switched to using gitsvn exclusively for svn projects I'm involved with
since I noticed that -- I save space and have complete project history
locally. What more could you ask for?

(p.s: git svn is a better svn client than svn. really)

------
cpeterso
My favorite git introduction/reference is "Pro Git" by Scott Chacon. The book
is available in print and online: <http://progit.org/book/>

------
bradendouglass
A a well designed and simple GIT Tut this seems to be easy to run through. In
addition, the steps are broken down into micro chunks which are always easier
to people who have no clue. Wonderful and thank you.

------
Lennie
What are the downsides of git ?

So far I only heared that git does not handle large binary files well and
supposedly it is good to keep your large source tree (larger than the Linux-
kernel !?) into many smaller git-repositories.

And you have to learn something new and unlearn bad habbits.

The no-easy-GUI-problem has been solved, right ?

~~~
silentbicycle
It doesn't handle large binary files well, but would you track patches on them
anyway? It doesn't fit git's model. Git deals with the current working state
of the _whole repository_ , not individual files.

A major problem with git is that if you try to use it without realizing its
fundamental model is different, it will seem awkward and complicated. Don't
think about it as "like svn, but distributed"; start from zero.

~~~
Lennie
For some projects you also want to track versions of binary files because they
go together with the code. And I read it was a bad idea to use git for those
binary files, exactly because git was not designed for that.

------
alanh
Hmm, the chapter index uses the information (i) icon. Bizarre choice, but
useful menu.

------
weixiyen
All it has is a link to the download for git. Is this a placeholder for
something?

~~~
nonrecursive
Try the "start" arrow at the top

~~~
weixiyen
thanks

------
lzell
The ultimate log format (lab 10, item 4) is superb!

~~~
brunoqc
I agree but I wonder if it would be prettier with colors.

When I added this alias to my gitconfig I found an old alias I had for a
pretty log, you may like it. <http://www.jukie.net/bart/blog/pimping-out-git-
log>

------
ylem
I found this to be a rather good tutorial!

