title: Git vs. Subversion for multiple large development branches
body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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?</p>
  
  <p>Second question: Are there other integration methodologies that may work better for our scenario?  In particular, I was reading an article about <a href="http://agile.dzone.com/news/promiscuous-integration-vs" rel="nofollow">promiscuous integration</a> 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).  <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow">This article</a> also seemed a good methodology for our situation.</p>