views:

503

answers:

8

Outside of work I use SVN for my personal projects I wish to keep private. I use it to synchronise sources between my laptop and desktop, for off site backup and the normal advantages SCM brings. The current trendy source control system is GIT and I must admit I'm considering moving to it. But given what I use it for and that I already work against branches what advantages does GIT really bring?

+1  A: 

Distributed source control allows local commits and you can do these offline.

While Linus's talk about git is very fun to watch and full of truths, not all of them are applicable to small teams or teams of one.

You can use git as a front-end with local commits to an SVN repo using git-svn. Using this with your existing SVN repo offers a back-out plan if you don't grow to like the tools.

There are of course other distributed source control systems.

Will
I did watch the Linus talk and it didn't really inspire me. Nice idea with the GIT to SVN bridge giving a back out clause.
L2Type
+15  A: 
  • It's faster than Subversion
  • You can have all of your history with you on your laptop
  • You can sync between machines without having to worry about whether your server is online/accessible/etc.
  • git stash is great for stowing away half-done changes
  • You can create a new repository by going into a directory and using git init, without having to do any server setup or administration
  • GitHub is a pretty nice place to host Git repositories
  • Why Git is Better Than X
Brian Campbell
Faster than Subversion on Linux. On Windows ... bleh
jpartogi
My experience has been that even on Windows, most operations in Git were faster than the equivalent operations on Subversion (especially as many Subversion operations need to talk to the server, while they just work locally in Git). But yeah, the performance advantage isn't as great on Windows.
Brian Campbell
@jpartogi git is much faster than svn on windows in my experience
John Nolan
I read @jpartogi's comment to mean that git on Windows is just about "bleh" in general, speed advantages notwithstanding, which I unfortunately agree with.
calmh
Is stowing half done changes the whole point of branches?
L2Type
@calmh Most of my professional work has been with Git on Windows, and it's worked fine for me, providing a much better experience than Subversion did. I primarily used Cygwin Git; some of my colleagues used msysgit, which required a little more work to get working, but once set up was perfectly smooth. What problems did you have?
Brian Campbell
@L2Type By stowing halfway done changes, I mean you're in the middle of working with something, it's not even in shape to compile, and you don't want to bother writing a commit message, you just want a clean working copy so you can work on something else and come back to it. `git stash` will just save your working copy and reset it to a clean state; then you can do your other patch, commit it, and do `git stash pop` to get your half-done changes back. Branches are usually for somewhat longer term changes, and you generally try to have complete commits that at least compile and pass unit tests.
Brian Campbell
When I was using Subversion, I would frequently be in the middle of something tricky, and someone would come up to me and ask a question, ask me to reproduce a bug, or want a quick one line fix to something. I would then do `svn diff > something.patch`, `svn revert`, do work, commit, `patch -p0 < something.patch`, `rm something.patch`. With git, it's just `git stash`, do work, commit, `git stash pop`; and it will keep track of multiple stashes if you have those, they don't clutter up your directory, etc.
Brian Campbell
@Brian Merely that there isn't (wasn't?) a nicely integrated client. TortoiseSVN does this OK for SVN, but the whole Cygwin plus terminal thing is very "un-Windowsy" and not a very elegant solution in my opinion. On Linux or on a Mac, git feels right at home, but on Windows it felt like an alien environment.
calmh
@calmh Nowadays, there is TortoiseGit and Git Extensions, both of which offer TortoiseSVN style shell integration. Of course, I'm a Mac and Linux user, so the first thing I do when I need to work on a Windows box is install Cygwin, Emacs, and a few other things like that to make it feel like home, and I'm perfectly happy with the command line.
Brian Campbell
+1  A: 

I recently did roughly the same switch you are contemplating. I'd say that yes, it is worth it, for the improvements in workflow that better branch handling, the index, and the possibility of working offline brings you. It's not a painless change though, a lot of concepts are sufficiently different to be confusing at first.

There are a few posts out there on the main differences between SVN and git that might be useful to read. This is a (biased) overview.

calmh
+2  A: 

For me it's been using Git in conjunction with github.com - it saves me needing to worry about setting up and managing the actual repository system itself meaning I can concentrate on the more important part - learning how to use the main commands themselves :)

I've not got experience with any other SCM platform so my opinion is probably a little on the basic side but it's been pleasant enough to work with - given that I'm in Windows it's also nice to know there's decent support in the form of msysgit.

Everyone is different I guess, but for me, a beginner really, it's been a very gentle introduction to SCM.

foxed
+3  A: 

I'd take a look at the below resource.

http://git.wiki.kernel.org/index.php/GitSvnComparsion

Some highlights are:

  • SVN requires up to 30x more space at times
  • Git is faster due to operations being local
  • Personally I think branches, merging, and such are easier to perform.

But the fact is you won't magically know how to use git or receive the biggest advantage of using it so I'd try it out with a couple projects and leave your svn repo open as an option later. Even though I doubt you'll want to go back :P

Jared
+3  A: 

I created an account on bitbucket for my personal projects, for two reasons:

  1. At work, I work in centralized source control system. I wanted to learn about DVCS. Mercurial seems better for Windows environment. So far, I like it.
  2. I want my source code backed up off-site.
Srdjan Jovcic
+4  A: 

Branches.

Branches just seem so much easier to create. You can work in the same directory and then switch between branches with one simple command. So you don't need to have a separate directory for each branch and it is much faster than any other scm I've used.

John Nolan
Mr Nolan, anyone would think that evangelise this at NxtGenUG
L2Type
Oh Hello Mister L2Type :)
John Nolan
A: 

I adopted the technique of using source control (first with CVS and then with SVN) to synch and backup my environments around ten years ago (probably more). It basically worked but I found it a little clunky and did not do as thorough a job as I would have liked, letting some systems get a little stale and succumbing to using new systems and avoiding setting up those systems for use with this scheme.

About a year or so ago, my son convinced me to try out git. Now, all my systems are synched and backed up to our family git repo hub, providing the personal privacy I require (ssh access).

I find the git usage model so easy to use that I now have a daily ritual of pushing changes from the machine I most recently used and pulling them to the next machine I use (there are typically five or so computers involved in my day-day work). Those answering before me have done a great job of addressing the git technical advantages. My testimony is to the ease of use advantage git has over svn, as applied to exactly what you want to do based on doing it for about nine months now.

That said, expect some discomfort early on as git is very much a different model and it takes some getting used to. But between SO, published books (I recommend the O'Reilly book) and abundant net resources, learning git is now easier than ever.

pajato0