Why would I not want a central repository in versioning? SVN vs. Git question [duplicate]

Question

Duplicates:

• Why should I use git instead of svn?
• Should I use SVN or Git?
• Why is Git better than Subversion?

I'm sure I've asked it wrong but I read that Git doesn't use a central repository like SVN does. One, I don't understand how you can have a decentralized version control system. I'm sure it works because so many use it but I don't understand the concept.

How can you have something everyone uses but not a centralized repository to hold the source code?

I suppose this is more of a git vs. svn also, Which do you use? I read that git is better but not as integrated in most IDE tools as SVN.

I'm still learning.

Thank you.

Answer 1

That always confused me too before I started using Git. People like to overemphasise how different it is.

The truth is that you can, and most likely will, set up your Git system to have a single "master" repostiory. What's different with Git is that every "working directory" also gets its own client repository. A large amount of Git's design is for merging code back and forth between client repositories and a parent.

If you want to go with a single master repository sitting on a server somewhere, and all users being direct clients of that repository, you can easily do that. What makes Git really different is that you don't have to do that. You could instead have a big tree of repositories from worker, to subgroup, to test group, to master if you want. You could instead set up a chain from worker to development master (updated frequently by developers) to remote customer site (updated rarely by the customer when they want a fix, and can get the private network up between them in Ethiopia and you in Toledo). The topology and workflow is up to you, not the tool.

My suggestion would be to try out Git yourself for a small (or pretend) project. Once you see how it works, you'll begin to see the possibilities.

Answer 2

The point of a DVCS is not "avoiding a central repository." Most DVCS-based projects I see have some notion of a common HEAD--people push patches to that HEAD, and that's where releases come from.

Instead, the primary advantage of a DVCS is that every working copy allows revision control. This has three primary advantages.

1. Convenience. If I add a new feature, I can commit it--and have a nice record of a working version of the code--without either having a network handy, or having to shove my possibly-broken code into other peoples' hands.
2. Control over parallel development. Totally independently, I can work on one feature set, and use revision control in all the ways that we know it makes development better, while someone else can commit patches to the same code (so they can take advantage of revision control) without interfering with my developme
3. Branching, merging, and the like. DVCSes tend to have much better support--since it's an inherent idea in a distributed system--for branching. If I don't like what the head of a project does, it's trivial for me to branch the project. I pull HEAD, start committing to that repo, and can send that repo to anyone who wants my branch. Similarly, in the context of #2, it's far easier to deal with multiple patch sets from different people.