Git vs. Subversion for multiple large development branches

Question

At my company, we are currently using Subversion. Our project development process consists of a "live" branch of code (this is what is on our live web servers), a general dev branch for smaller projects, and then each larger project has its own separate branch. We usually have at least 2 larger project in development at any given time. Merging those back into the live branch can be a pain, but what's more of a pain is when large project 1 goes live, then large project 2 is going live a little later, and that merge process is just... messy.

What I've been doing in SVN is to have a daily merge from live (so any bug fixes etc. that happen) to the development branches. But the larger project merge process is still messy, and I'm wondering if it will be cleaner with Git. As one example of something "bad" that's happened with SVN, we will have a small feature on dev, merge that to live, then when performing the live backmerge, SVN tries to merge that feature back into dev again (causing a conflict), unless we manually deselect that commit in the merge. From my understanding, Git is "smart" enough to know that commit originated in dev, so it wouldn't try to merge it back in... but my understanding could be wrong. I also hear that Git is better at automatically handling complex merges like we're trying to do.

So, first question would be: is Git notably better than SVN for what we're doing, or would we still likely run into the same issues and just-as-hairy merges?

Second question: Are there other integration methodologies that may work better for our scenario? In particular, I was reading an article about promiscuous integration that seemed good, though that also seems like it would get exponentially harder the more projects are going simultaneously. But then again, I don't expect us to ever have more than three big projects at the same time, and usually just two. Continuous integration isn't an option for many of our projects, because they tend to be all-or-nothing projects, or ones that would be jarring to users if pushed in parts (e.g. our recent redesign of our checkout process). This article also seemed a good methodology for our situation.

Answer 1

We let people use whatever tool they feel most comfortable with. git-svn offers a git-lite experience for folks that are more comfortable with or want to learn git for professional development. There's a project out there called SubGit which will let you have SVN and Git for whoever wants to use either.

Generally speaking, folks that branch/merge a lot according to the feature branch development style tend to prefer git. It's also a lot less overhead for several team members to collaborate independently of the rest of the group.

Answer 2

Try git, you will not go back.

I would say stick with Svn ONLY if you don't do any merging (i.e. work on trunk in a small team). All other cases, including yours for sure - git will make your life easier.

Git is way better than SVN when it comes to branching, merging and resolving conflicts. Think about SVN "one checkout dir per branch" scenario for instance. Moreover, git is so much better with merging/branching, that some people are using git-svn to merge SVN branches. Imagine that the other way round...

Also, This answer is pretty good at explaining Git vs SVN.