Should I understand SVN before I jump to GIT? [closed]

Question

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?

Are there pros and cons to both approaches?

Answer 1

No

Git is so radically different from SVN it won't help you. If anything you will be looking for "update" and "commit" commands and wondering why everything is different.

Start with Git from the Bottom Up and go from there.

---

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.

Answer 2

No, please don't even bother.

Seriously, start from a DVCS. The fact that SVN is popular doesn't make it the standard. Linus Torvalds would tell you that it might rot your brain.

Read this great article/introduction by Joel Spolsky called Subversion Re-education.

You might also be interested in reading this other question: I'm a Subversion geek, why I should consider or not consider Mercurial or Git or any other DVCS?

Choosing between DVCSs

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.

Quoting Thorbjørn on this other thread:

DVCSes are to Subversion, what Bittorrent is to ftp

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.

Answer 3

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.

In the end, learn what you intend to use.

Answer 4

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.

Answer 5

It would be counter-productive to learn svn and then git

Here are a few reasons:

• Gits radically different from svn. Git's distrubted and svn is client/server.
• Different meanings are attached to the same words. For example 'git checkout ... ' has a different meaning from 'svn checkout ...'
• Branching is different. Git has this concept of 'topic' branches which are cheap local branches which svn doesn't support.
• Git has an extra place, called the index, that sits between the working tree and your repository. Svn has no index. Using git your changes move from your working tree to the index to the repository.

My advice is to just learn git.

Answer 6

There are some things broadly the same in GIT and SVN and some not.

Create/update/checkout/commit

Broadly the same, you should pick it up easily.

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.

Answer 7

Wow; 12 answers and everyone is still begging the question...

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.)

Answer 8

Probably not - there are sufficient differences between server based and distributed that you'd probably only confuse yourself further.

Set out from the start to follow good practice with the DVCS of your choice as if from scratch and you'll probably be a lot happier.

Go look at Mercurial (if you don't want to be overwhelmed).

Answer 9

Git is only marginally more complicated than Subversion, because there's a distinction in Git between committing and pushing to the central repository.

It's worth learning Git while you have the chance to have your mind undestroyed by Subversion.

Answer 10

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.

Answer 11

I really like git in Unix environment (Linux, MacOS X). In windows, it is a little bit hacky. I would consider Mercurial if I have Windows in the equation.

I you liked your histories classes, try SCCS, RCS, CVS, Subversion and then use some thing useful like Git or Mercurial.

Git and Mercurial are equipotent, the big bonus of Git is github. But if you don't want to outsource your version control, github is not anymore in the equation.

Answer 12

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.

Answer 13

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.