I work in a department where no one has ever used source control before, including myself.

I am trying to push the concept. I have spent a little while researching SVN. I some basics learned. I can Create/update/checkout/commit with command line and from Tortoise. I am starting to learn how to tag and branch but still confused a lot about conflicts between branches and trunk etc. I am still learning, but I do not have a physical person who can show me anything. Its all from books/tutorials and trial and error.

From what I have read online it seems like git is the better thing to know, but its also more complicated. I don't want to overwhelm myself. Should I continue to master svn before moving to git or would I be wiser to just jump to git now?

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

No, it will cloud your mind and then you will need "subversion re-education". Also git/mercurial are the better technologies. Training your co-workers in subversion will make it harder to switch to the best tools later on.
–
KeyoJan 11 '11 at 5:59

Contrasting a standard centralized update / commit pattern versioning system with Git is like comparing a bus with mass transit. A bus will get you (and everyone else) from point A to point B using the exact same route. Mass transit will get you from point A to point B using whatever route you like.

Distributed itself has disadvantages you should be aware of. It takes more work to keep everyone on the same page. It offers a huge increase in flexibility though.

Revision hashes vs. Numbers

Someone mentioned Git using SHA1 hashes while Hg uses numbers.

First you rarely (if ever) need to deal directly with the hashes in daily commits / pulls. You need to pull up the log and pull hashes if you are doing diffs or some of the more tricky rebasing items.

With Git, everyone has the same hashes. Different repositories don't have different commit numbers and everyone is on the same page. With Hg this is less so. In practice if you have to pull up the commit hashes and work with them (either for comparing or traversing the code's timeline) it's easier to sync with other people when you have hashes instead of numbers.

Personally, I use both mercurial and git, and I think that it is important to know both. A recommended reading about this is Git vs. Mercurial: Please Relax (see the git-addremove example). Two quotes from that article that I think sum it up.

Regarding git:

Git’s design philosophy is
unmistakably that of Unix: unlike
Subversion, CVS, or Mercurial, git is
not one monolithic binary but a
multitude of individual tools, ranging
from high-level “porcelain” commands
such as git-pull, git-merge, and
git-checkout to low-level “plumbing”
commands such as git-apply,
git-hash-object and git-merge-file.
So, like MacGyver, you can do just
about anything you need with Git –
this includes totally awesome Wiki
engines, issue trackers, filesystems,
sysadmin tools – everything short of
fuse repair.

Regarding mercurial:

Developers who like to keep their
system clean will probably appreciate
the fact that hg installs one binary
in contrast to the 144 that make up
git, and developers who think that
git’s ability to edit your previous
commits is moronic, unnecessary, and
dangerous will appreciate the
simplicity hg provides by omitting
that particular feature.

A lot of projects can be found on github and git is more powerful, but it can also be somewhat intimidating to newcomers, specially windows users. There is also bitbucket (github's equivalent for mercurial).

My recommendation: start with mercurial and as soon as you feel comfortable with it, pick up git; it is not about the tools, it is about the people you work with.

What I consider subversion's real and practical use is, not for working with other people, but for perhaps to implement an updater for your production applications, here is why:

Currently, svn is almost installed in most hosting providers

Has good subproject support (addressable in git and hg now, though). svn up and your project and its dependencies get updated.

Edit: If there is a VCS you should know before Git, that could be Mercurial (way more friendly CLI interface and good to get introduced to the distributed concepts). This advice applies specially to those coming from Subversion since the CLI is also similar in some degree. Distributed Version Control can be easier to learn than Centralized Version Control, since you just worry about your repository instance, and not the client and server parts in separate.

+1 for useful links. Subversion is easy enough and well-documented enough to be able to pick up as necesssary once you have the ideas of source control in your mental model.
–
Gary RoweJan 10 '11 at 17:26

You should be learning what you intend to use. Git is popular, just as Mercurial also enjoyed some popularity. Git/Mercurial are both distributed source control systems.

The most important thing when introducing a new concept to a team (and it is unfortunate that version control is considered a new topic for too many teams), it helps to outline your goals and evaluation criteria. You don't have to be super-formal about it, but ask yourself the following questions:

What's the purpose of version control in our team. Yes, all version control systems worth anything will let you go back in history and see what has changed in any given file. However, are you going to use it to baseline new releases? (nod your head, you want this). This is the 2-3 line vision statement for what you want to accomplish.

Is your team used to having their own local work environment only to merge things carefully later on? If so, the DVCS route might make most sense.

Conversely, is your team used to working from one shared drive and everything is in constant integration? If so, the more traditional VCS might make the most sense.

When evaluating your alternatives, you have to consider the important things all VCS's need to do:

Baseline code (tagged branches, labels, etc.). Basically, how do you get the exact source code used in a release of your project.

Get local changes to the central server. There needs to be an authoritative copy of the code--whether you use DVCS or standard VCS. Each tool treats this process differently.

Get changes in the central server to your local copy.

How to deal with experimental changes. VCS's allow you to be more daring with proposed changes without breaking the main project source code. DVCS and standard VCS systems approach this very differently--one of those will work best for your team.

How do you set up and configure the servers?

Do you need authentication? If so, how do you make sure only the people who are permitted to make changes actually can?

In the end, do a quick evaluation to determine whether standard VCS or DVCS systems are going to be best for your team. You'll have to pick the tool that provides the least amount of pain or it will likely not get adopted. After that, evaluate your alternatives that best match your needs.

I think that a lot of people find git more complicated than svn because it's different. After using subversion (or cvs, etc.) for a while, it can be hard to mentally switch modes into a DVCS model. Based on that, I would say it may behoove you to research traditional VCS like subversion in tandem with researching a DVCS like git.

Although git is my preferred VCS, I would say that it's probably best to learn subversion as well. For one, there are still a lot of subversion and cvs repositories out there that you might have to interact with one day, and also you'll have a better understanding of the precise advantages and disadvantages of DVCS over traditional VCS.

how to tag and branch but still
confused a lot about conflicts between
branches and trunk etc

Different between the two.

Not saying you should or shouldn't change now (I think that's your call), just wanted to point that out as it's something to take into account. If your sure you want to try Git, you may decide to switch now to save yourself learning something in SVN that is different in Git.

Also, don't listen to the subversion bashers :-p Git is very "cool" at the moment and svn very uncool, but both have their place. Using either is miles better than not using anything so good on you for introducing this. I've introduced VC to 2 small companies, it's hard but worth it.
–
JamesJan 10 '11 at 17:32

+1 Great info thanks. Seems like if I was going to jump, now would be a good time.
–
JD IsaacksJan 10 '11 at 17:41

No, Subversion is not a prerequisite for Git.

There is no clean mapping between Subversion and Git -- if you plan to learn both, you will just have to suffer through the fact that they use the same terms for different actions. (And different terms for the same actions.)

svn commit is a different thing than git commit.

branches in svn and git are very different

an svn repository is more like a git remote (but not really)

a git repository is more like an svn working copy (but not really)

These are two tools divided by a common language.

Your question, and most of the other answers, presume that git is some kind of svn++; A "better svn". It isn't. The two are different tools that work in the same space, like a car and a motorcycle.

I would suggest that you pick one, master it, and start using it on your team. Learning version control is going to be hard for people who have not used it before. Your VCS is going to be an important part of your infrastructure, and learning to trust it involves building new work habits. That takes a while.

(Either way, make sure you have your sysadmins back up the master repository -- losing your source control would be catastrophic.)

If you downvote please at least give me the courtesy of an explanation. Thanks. Two possibilities: 1) I might fix the answer or 2) I might delete it... but only if I actually know why you think this is flawed
–
MurphJan 10 '11 at 17:55

I don't think understanding Subversion is necessary to understand Git.

The biggest difference with Git and Mercurial from Subversion, to me at least, is that you have a local repository that you work with, you check into and out of there until your code is working, checkout from the central repo, fix any conflicts and check back in and push to the server.

Version control systems share something in common with programming languages in that the first one you learn will take the most time. After that, picking up a new one is just a matter of learning how core concepts are expressed by the new system.

You can learn Git now and invest time in learning Suvbersion later if you need to.

Nope. Download Git, create a github account, and mess around for a couple of days forking repos, etc. Git is pretty trivial to get up to speed with. Learn 5 or 6 bash commands and you can do all of the essential tasks. I generally prefer the "idiot-proofness" of a GUI, but the Git Bash is about as easy as it gets. Also, the Git Gui is pretty decent if you prefer that route. I do not really see the benefit you would see from learning SVN. I went through a period a while back where I was evaluating a few different Version Control systems for a new open source project. I tried out SVN, Bazaar, Git, and a couple others and learned the basics of each. YMMV, but Git was by far the easiest. There is nothing wrong with learning SVN as well, but it really will not help you to learn Git.