Git Immersion

http://gitimmersion.com/

by tortilla • 16 years ago

247 38 16 years ago

gitimmersion.com

weixiyen2• 16 years ago

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

nonrecursive• 16 years ago

Try the "start" arrow at the top

weixiyen2• 16 years ago

thanks

johncoltrane• 16 years ago

It's a Git tutorial. Click on the "START" black arrow to start the ride.

alanh• 16 years ago

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

roel_v3• 16 years ago

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?

mrchess• 16 years ago

The only explanation needed is a fact. Linus Torvalds made git. Sold? :)

bradendouglass2• 16 years ago

Sold me

roel_v3• 16 years ago

Seriously? Are the upvotes because your comment was funny or is this actually a factor people make their tool choices on?

kgrin• 16 years ago

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.

balac• 16 years ago

The killer combination for me is branching + distributed. Your branches don't have to be mirrored on a remote server for all to see.

Branching & merging are also insanely easy to do, so I find that I develop almost all new features in their own branch, and I can easily just throw them away if I want, I never did this with subversion.

roel_v3• 16 years ago

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?

pacemkr• 16 years ago

As a recent convert to git (from hg), who didn't "get it" before, I think you have to qualify what you mean by branching works.

Effective branching is the killer feature of git or any source control system, to me. And in that regard:

svn < mercurial < git

svn: Three way merges are close to impossible. When you do a three way merge of a file you need to find the common ancestor of all three versions. This is just an incredibly difficult problem in svn that to my knowledge can't be solved in a way thats durable. In mercurial and git you can simply walk the graph to the common ancestor.

mercurial: Somewhat fails at the concept of a short lived local branch. You can't create a local branch in place--without cloning the entire repository to a different folder--to try out some feature and then delete the branch if it doesn't work out. At least not without using bookmarks or extensions: mq, localbranch. With these you get a bookmark, a patch queue, or an in-repository clone, respectively. None of these are branches in the fundamental sense.

git: You can get a short lived local branch, a long lived one, a release branch, a bug fix branch, a feature branch, branch, branch, branch. In git branching just works, and that, to me, if compared to mercurial, means specifically working local branches that are not fundamentally different to the rest of the repository.

ulf• 16 years ago

The whole distributed concept really works. No more "WiFi is down, so I cannot commit". As well rebasing is a nice tool which saves a lot of headache, especially for people trying to figure out what you did a lot later...

smiler• 16 years ago

How is this an advantage? Whether or not I can commit locally does not make much difference to migrate my changes into a central repository for other developers to see...

wallflower• 16 years ago

Imagine if when you made a Git branch and then attempted to merge back to master that you got errors saying that it could not complete. Even after trying all your Git Foo. In other words, that you would now have to checkout the main trunk of the project and manually merge your changes (by backing up your failed branch with a file system copy). Yes, svn merge and svn reintegrate usually work but there are times where the entire process completely fails and makes you want to do shots at 3pm on a Monday. (Good luck if someone deleted files you have in your private branch!) You Git developers have it good. Branching is like breathing to Git, while it is like a dental checkup in SVN. I prefer Git and avoid svn branching since it is like touching a hot stove. So basically I have to keep up with the SVN trunk and I cannot merge WIP because I am not on a private branch. To keep me sane.

Peaker• 16 years ago

Merging, cherry picking, scalability/speed, rebasing, synchronizing multiple remote repositories, no need for commit "rights", and github are my reasons for preferring git over svn...

kondro• 16 years ago

Repositories are also fast and small.

Fast because every clone is a local copy of the complete repository with all commits and branches.

Small because of the way it stores it's diffs.

Subversion tends to be really slow when doing branching, merging and getting commit logs because it always needs to communicate with the remote server to transfer files and data.

Subversion checkouts seem to be really huge because it will have a version of the latest head and a version of what you are currently working on.

RyanMcGreal• 16 years ago

Seconded. Git is amazingly fast.

davidwparker• 16 years ago

This may be helpful, to some degree: http://whygitisbetterthanx.com/

axiak• 16 years ago

While there are a lot of lists that proclaim what's better about git -- at some level you're right: you can do the same things in subversion than you can do in git. (Even though svnmerge doesn't really do nearly the same things as git merge.)

That being said, I've witnessed the main gains of git after using it for a while. It is no longer a chore to branch and merge, it's instantaneous. It takes no time to commit. There is no penalty to committing -- my commits don't make it to everyone else until I'm ready to send my commits. This means that in a git environment I find myself committing, branching and merging more often.

Over time, you find that the increased number of commits and branches helps you to collaborate with others in ways that you just weren't used to thinking about in subversion.

If you are always working on things very linearly and are never context switching (and your peers aren't context switching), then you will notice no change with git. However, I have never worked at a place where this is the case.

spacemanaki• 16 years ago

This isn't really an explanation of why git is better than subversion overall, but it was a pretty big eye-opener for me, and I'm definitely still learning the basics of git: http://tomayko.com/writings/the-thing-about-git

To sum up, git solves what Ryan Tomayko calls "The Tangled Working Copy Problem" with amazing ease. If you have a working copy filled with changes, git add --patch lets you pick and chose which files, and even which changes within a file, to commit. It's obviously possible to do this manually with svn (or even cvs) but git just makes it so easy.

Xurinos• 16 years ago

Others mention the super-fast branching. One person mentioned partial add/commits. Someone mentioned the size difference (it is HUGE... your checkout of one SVN revision in a large repository will be six times as huge as your entire git repo and checked out files!). There is history revision (split a commit, squash some commits together, reorder them, separate them into different branches, deploy what you want! it's like editing a document!). The user interface is helpful and informative if you understand git lingo and version control theory; for example, if you misspell a command, git intelligently suggests commands that are similar to what you meant. On these things alone it blows SVN out of the water.

But to pull a page from Linus's playbook, since no one mentioned it: git fsck. No other SCM I am aware of can fix itself in the event of a small corruption. I have on rare occasion had to deal with these corruptions on network shares, and a "git fsck" brought me back to life in a jiffy. This is really useful for recovering work on your unshared local branches.

billybob• 16 years ago

Well, here's why distributed is better than centralized:

You're working on something in SVN. You've made progress that you'd hate to lose, but it's not great yet. Which do you do?

1) Don't commit until it's great. This prevents bugs from hurting your colleagues, but puts you at risk of losing work or being unable to undo mistakes - in other words, it's just like not having version control.

2) Commit a lot. Opposite problem - your teammates get your bugs.

Distributed version control lets you have both benefits: commit locally as often as you want, and push it up when it's good.

(I think I stole this explanation from Joel Spolsky. Whoever said it, it was what made me realize I should learn a distributed VCS.)

P.S. If your answer to the dilemma above was "use a branch until you're ready," well, OK, but branching in SVN is painful and slow, requiring making a copy of every file in the repo.

bradendouglass2• 16 years ago

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.

ylem• 16 years ago

I found this to be a rather good tutorial!

cpeterso• 16 years ago

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

lzell• 16 years ago

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

brunoqc• 16 years ago

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

Lennie2• 16 years ago

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• 16 years ago

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.

Lennie2• 16 years ago

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.

Git Immersion

Related Stories