GIT or SVN or... for front-end developers_问答_开发者

I recently began importing a number of our projects into a Subversion repository at work and over the next few weeks i'm expecting every one on the team to take responsibility for their own source control management.

The reason I chose SVN over GIT is that I want everyone on the team, including designers, frontenders, integrators... to take charge of their own SCM and so i'm expecting things will move quicker if they manage their work using a GUI (Cornerstone for mac and Tortoise SVN for windows). I know there are some GIT GUIs out there, SmartGit looks most appealing at the minute, but none seem as capable as their SVN counterparts. Besides, I feel we'd be losing something in translation by not using the command line to w开发者_Go百科ork with a DVCS (whereas i'm significantly happier using a GUI to manage projects in SVN).

The problem is that distributed solutions are fast overtaking centralized solutions and so I'm wondering if it would really be worth the extra investment now rather than have to migrate everything 6 months down the line and invest time in a DVCS anyway? The other way to look at it is that SVN would be a relatively painless step in the meantime which would prepare us more adequately should we later decide to migrate to a DVCS.

Your thoughts and experiences are appreciated.

*Aside: for a number of reasons, I prefer multiple projects per SVN repository. This, though, means less meaningful statistics from Atlassian's Fisheye, as well as being messier. If we did decide to use GIT it would be 1 repository per project.

One thing to keep in mind about DVCS is that it's not actually about the distributed-ness of it, it's about the branching and merging. DVCS makes branching and merging much easier, to the point that each developer/designer/front-ender basically has their own private branch -- their local repo. That way, they can work in parallel without stepping on each other's toes. That means they can be checking in code every few hours instead of waiting days until they have everything done to check it in.

I would suggest you look at Mercurial. It has a good GUI in TortoiseHg and I find it to be easier to get started with than Git, just because it doesn't present you with all the advanced stuff right at the beginning, but it still has all of the powerful functions once they're comfortable in the system.

I don't believe distributed solutions are fast overtaking centralized solutions because so much of the development is not distributed. Git was designed around the issues people working on open source projects run into but most of those are not issues for an individual enterprise managing their code.

Just like you did, the well developed tool base for subversion was a key reason we picked it. It integrates easily with all the development tools people use plus our ticket system.

Try and introduce a few user to TortiseGit. Depending on how they react to it, you can decide if ti works for the team. If they're struggling with it for more than a week or so, try out SVN.

If they really feel more comfortable in SVN, than I would go with that. The advanced devs can still use git-svn to make use of most of the advanced features of git.

Of course distributed-ness is nice, but if svn had the same non-distributed features git has, only Opensource-people working on large projects had started to use git in the first place. Merging and branching is very nice, but moreover: If you screwed something up it's usually very easy to solve the problem when using git. Or if your source code is full of changes and you quickly need to solve an issue of the "main code" git saves a lot of pain. When we started using svn at the company I work we had a loot of problems with it. Mostly because it lacks a lot of flexibility.

But in the end I guess you should make your decision depending whether you find a good GUI for it.