对于单个开发人员来说，是否值得从SVN转到Git？

Question

--- THIS THREAD IS VERY LIKELY OUTDATED AS OF 2013 ---

Is it worth going to GIT from SVN when the repositories are mainly accessed by a single developer? I have several machines that I use for development and not mainly develop in C#. But I have a mix of VB, VB.Net, PHP, C#, C++, HTML, Batch, BASH and many more in my repositories. What, if anything, will I gain by migrating to GIT from SVN? Right now use TortoiseSVN + VisualSVN Server with a set of central repositories and several client machines. While I have granted a few friends access to my repositories they do not Update or Commit often (if ever).

Also is there a way to have the flexibility and ease of maintenance I get with VisualSVN Server + TortiseSVN with Git?

((I'll bite... what other platforms and trickery would be compelling for a single developer/small group?)

Please List Pros and Cons not just one sided opinions.

Current Tool Chain... Visual Studio 2008 (C#/VB.Net) + TortoiseSVN + VisualSVN

Main Focus... XNA Games, WCF/Socket Services, Web Development

Answer 1

I can give you three advantages:

1. You can have multiple back up repositories. Git isn't centralised, so you can keep your repo on whatever machine you're working on and push changes to any back up locations you have. I keep my repos on github , and two other locations.
2. Branching, merging, rebasing, amending commits, git bisect. Just because you are a single dev, there is no reason not to use the best tools.
3. git-svn - you can give it a try in parallel with your subversion repos while you make your mind up.

There is a disadvantage; and that is that the visualisation tools available on Windows are not as user friendly as those that are, perhaps, available for other platforms.

Answer 2

Yes, of course.

You're misunderstanding what git is. I mean, why would you assume it's only useful for teams?

git is even more worth it if you're a single developer.

Pros:

• svn requires a server to run in the background. git on the other hand, is a simple utility, you just run it as if you're running grep or ls or any other simple command line utility. You don't need to setup any server or anything like that.
• The .git folder is the entire repository, you can take it with you anywhere (for example, on a USB stick) and it will always have your repo. Your entire repo, along with its history, and everything else, and it's actually compressed very well, so it doesn't take that much of space. (Hint: that's why git doesn't need a server; when you run git commands, git just changes the internals of the .git folder).
• Branching and merging is really easy. You can work on experimental new features on a separate branch, and only merge when its stabilized. Meanwhile, you can do maintenance work on the master branch (eg bug fixes) and all the while you can keep merging the bug fixes from the master branch into your experimental (topic) branch with ease.
• This point is subjective, but I find it much easier than svn. I tried to use svn for a while, but found it too complicated, and often it got in my way (I don't exactly remember that what's and why's, I just know it wasn't a pleasant experience). For example, renaming files is not an issue. You can rename files and git won't make any fuss, it just doesn't care about the file name. The only thing is, you have to remember to add it after you rename it, it's as if you created a new file.

Cons:

• Not many visual tools. There's a git-gui, it's not bad, (I haven't used it much) but you don't wanna depend on it. You need to get used to using it from the command line. If you're used to visual tools with svn, this maybe a con, but in my opinion, the only con here is that you have to step a little bit out of your comfort zone to learn it; but trust me it's worth it.
• There maybe some issues with line-ending on windows, it's not a big problem if you're the only developer, but if you're developing on windows and others are developing on linux, you need to make sure that all files use unix-style line ending instead of windows', in order to avoid any issues.
• Due to lack of visual tools, resolving conflicts (when they appear) might be trouble some at first. I personally use WinMerge, and invoke the command winmergeu <conflictfile> on every conflict file, to resolve conflicts. (Note: WinMerge is not a command-line merge tool, it's a visual merge tool, with a normal gui).
• This brings me to another point. While it's really easy to get started with git, there maybe some learning curve to dealing with issues that come up later (such as conflict resolution). If you don't branch and merge, then you won't even run into conflicts, but then again you'll also be missing a very powerful feature.

UPDATE:

I didn't notice the bit about you working from several different machines.

It doesn't make a difference, you just have to remember to push and pull whenever you switch to a different machine, but you already do this with svn: commit/update.

You'll get the power of branching/merging. Don't under-estimate this power.

How many times have you thought of implementing some crazy idea, but never dared to do it because you don't want to mess up your code? git relieves you from these worries. Just do it in a branch, if it works out, merge it to the main branch, if it didn't, delete the branch and forget about it.

Sure, you might say that you can do the same with svn revert , reverting back to the revision before you started the crazy idea. but what if you had bug fixes applied in the meantime? If you revert your crazy idea, you'll lose all the bug fixes/maintenance work you did while experimenting with your crazy idea.

Answer 3

Apart from what has already been said, If you're a single developer and haven't experienced troubles with SVN I see no reason to switch. svnserve (the daemon) works fine locally (I have OS X).

TortoiseSVN is a blessing compared to Git tools… is there any particular reason why you'd like to move away from Subversion?

Answer 4

It really depends on your workflow. Do you work often from places where you cannot reach your svn server? Do your projects have a large number of branches because you like working on several (big) things at the same time? Do you copy working copies between machines? Do you split off new branches from an existing branch? Do you sometimes work on the trunk and halfway through a bunch of changes think "I should have done this in a branch"? If so, then it may be useful.

From a single developer's point of view, the main difference between a central system like svn and a decentral system like git is that in svn the revisions are linear. With git it's a tree. This is useful when you work on bigger features that you want to do in multiple commits.

Example: You have a big feature F that consists of changes a, b, c and d. With Subversion you'd either commit a, b, c and d separately on the trunk, or you'd create a branch which means you have to do a lot of merging. With git you check out a working copy, commit a, b, c, and d on it. Then you'd push that as a single change F to your master. So, instead of four commits you see just one commit on the trunk. This makes it easier to see from the log what is going on.

You could do this with svn branches as well. But now suppose that part a also consists of multiple parts, like a1 and a2.

Such a development model can be done with Subversion. Python Twisted is done that way for example. All development is done on branches and nobody works on the trunk. But git makes such a workflow easier.

Answer 5

I have used these systems in the manner which you describe, under Windows with Visual Studio 2008:

• Visual Source Safe
• Subversion
• Mercurial
• Git

If you value your life, do not ever use Visual Source Safe...

Subversion

• Pros: Excellent tools, both on the server and client side. VisualSVN and TortoiseSVN .
• Cons: It doesn't handle merging things too well.

Git

• Pros: Excellent merging support, fast.
• Cons: Windows tools are almost non-existent, the GUI ones that do exist are so horrible, I hope I don't ever have to use them again. (my opinion)

Mercurial

• Pros: Excellent merging support, decent tools. TortoiseHG and VisualHG , Python based - hook scripts can be written in Python, hooking directly into the HG api.
• Cons: Tools are not up to the same par as with SVN.

Answer 6

One thing that may be compelling about Git is that you can continue to work and do commits offline. So, when you are on the plane, bring your laptop and commit as usual. When you are back online, you can push back to your main repo.

If you find you do a lot of branching you will probably prefer Git, as it is designed around making branching/merging easy and commonplace.

Update: Note you can test out Git without committing to it, since Git can talk to SVN repos . So give it a try, and if you don't like it, nothing lost!

Answer 7

Just try it, install msysgit , then

git svn clone svn://mysvn/repo/

Some of the resources in Git for beginners: The definitive practical guide should be of help ( Gitcasts and Git Magic especially)

Personally I find git much more pleasant to use in general. I switched my personal SVN repos to git about two years ago and haven't had a single problem with it ever

Not having to worry about your SVN server is nice (no need for constant network access to it), so is being able to trivially create repositories (they're just a folder containing another .git folder), perform any operations (commit, branching etc etc), then decide to put the code on Github with a simple command or two.

It's generally much "snappier" (almost every action basically instant), everything works "offline", clones are complete backups.. but the main reason I keep using it is Github

Answer 8

No. At least not for me. What's the point of having a non-centralized repo for a single dev?

Also, the Git Windows tools aren't quite up to the TortoiseSVN bar.

Answer 9

Some time ago I did that move from svn to Git. I agree with several of the above answers about advantages of Git distributed architecture over svn (like ability to take my repo with me on my notepad), but the compelling reasons were much more mundane.

• Svn is quite cumbersome, it puts his things (.svn folders) everywhere. That makes hard to use common command line tools like grep (and many others) on .svn repositories. In my project I also had some installation procedure that needed to copy a full ressource tree to some system path. When using svn I had to write extra code (or export repository), just to avoid that my installation procedure also copy .svn. That kind of problems totally disappeard using Git. All is in one .git directory at root of repository.

Nowadays (2/2013) there is only a single .svn folder in root folder present!

• I had several bad experience with my svn client on Linux, seemingly simple actions like moving a file and then modifying it before committing caused system hangup using 100% CPU! (And no, it was not something else that caused the crash and I could repeat it at will). Never encountered such problems with Git tools.

• I also had some terrible times merging code between trunk and stable branch on my old svn repository. It's really easier with Git.

Now, I made that move because I really felt bad using svn, if it works for you there is really no compelling need to change. The real task of a programmer is working with code, repositories are just tools that should at least not get in his way. And that was exactly why svn didn't worked for me.

Answer 10

Look into Bazaar (bzr). Seriously, it is amazing. Best merge capability I've seen.

Answer 11

If you are used to Tortoise SVN, then you should try Mercurial, which has a Windows package with a similar shell extension Tortoise HG . Also Joel Spolsky is using Mercurial at Fog Creek (according to him in one of his podcasts).

The package is completely stand-alone, I was able to install and use Mercurial right away (doesn't even need a server!)