Can someone explain Git to an SVN user?

I am familiar with SVN and CVS, and I’ve been hearing a lot about Git lately. What is so special about it? Reading the Wikipedia page is frustrating, because while it quotes Linus regarding just how awful he thinks SVN is, I can’t figure out what in practice is the core difference. How would Git make my life easier (aside from speed, although I’ve never thought of SVN as slow)? Articles also seem to mention how Git is “not dependent on network access”, which makes no sense to me. Obviously any versioning system will require network access to sync changes with others. There must be some simple way of explaining what the difference is in practice.

Once you start using git, you’ll realize how slow SVN really is. :slight_smile:

The primary advantage to git (and also the thing that is hardest to learn) is its totally distributed nature. Subversion and CVS require central repositories from which everyone downloads the code and to which everyone sends changed code.

Git has no central server or repository; everyone has a complete repository on their local filesystem and changesets can be pushed to anybody else’s repository. This means you can check in changes frequently “offline” – check in a change every time you edit a single line if you want – and you don’t generate any network traffic until your work is complete and you send the changeset somewhere else.

As a practical matter, most projects will designate a given repository as “official” and all changesets will migrate there eventually. If you’ve only got a small group working on the project then the model will probably not be too different from SVN.
Git also supports extremely cheap branching (svn requires a copy, and while this is still a copy-on-write, it can be painful for large repositories) which makes it easy to experiment in different directions while maintaining a complete revision history. If the experiments don’t work, it doesn’t matter, you just don’t push that branch anywhere and nobody has to see your stupidness.

I recommend this tutorial which comes with the git manpages for getting started.

Sounds really cool, especially the cheap branching, but it also sounds like a total nightmare to maintain some kind of stable HEAD version, and to prevent runaway forking. This is the part I still don’t get.

As a simple example, say you have three people modifying one file, and once a week the file needs to be compiled and executed at midnight. Bob, Alice, and Phil all have forked off to conflicting versions. By the end of the week they will need to merge their versions into a stable tagged version. Since there is no central HEAD, it seems unnecessarily confusing and even politically difficult (whose changes go in first, who decides conflict priority?). Something of a Mexican standoff. It seems like it could only get worse as the project gets larger. Am I missing something?

While there doesn’t have to be a central repository, nothing stops you from saying “this over here is the official central repository” and making sure everybody checks their stuff into it.

Git’s diffing and merging is very good, and it can deal with multiple changes to the same file easily. If there are conflicts (two people editing the same part of the same file) then those will have to be resolved manually, but that’s true of any revision control system.

Pretty much this. Also, because branching and merging is very quick and good in git, you can often maintain “parallel branches” to keep work from diverging too far. Example: you have a master branch that’s on the official repository, which tracks the “official latest working version”. If you’re also working on a new feature that can’t be pushed directly onto the master branch (for instance, because the current state of that feature breaks important things, or because you’re not sure the feature is going to work at all) you can do periodic merges or rebases from the master branch into your feature branch, which makes it easier to eventually merge the feature into whatever is the then current HEAD of the master.

And because git is completely distributed, you can keep the feature branch to yourself, or share it with only the people who need to work on it, until you’ve merged it into the master or published your feature as a separate branch on the official repository.

And you keep all the advantages of having a real version control system at any point. You can even rearrange commits etc in your own repository and only publish ‘cleaned up’ versions if you want to, so the official repo isn’t overwhelmed with “oops, quick fix for the last commit” commits.

Off topic but lol.

Git is an insult in British English- now somewhat detoxified but still pretty bad.



Prize for the first person who gives a derivation for ‘git’

Edited to add:

Forget that- its on WP now, didn’t used to be.

So is it better than bazaar?

I think (though I haven’t used bzr extensively) it’s comparable and they were both developed at roughly the same time. Git seems to be a little faster on complex operations.