Why is Git better than Subversion

Question

I ve been using Subversion for a few years and after using SourceSafe  I just love Subversion   Combined with TortoiseSVN  I can t really imagine how it could be any better     Yet there s a growing number of developers claiming that Subversion has problems and that we should be moving to the new breed of distributed version control systems  such as Git     How does Git improve upon Subversion

User · Answer

It s all about the ease of use steps required to do something   If I m developing a single project on my PC laptop  git is better  because it is far easier to set up and use   You don t need a server  and you don t need to keep typing repository URL s in when you do merges   If it were just 2 people  I d say git is also easier  because you can just push and pull from eachother   Once you get beyond that though  I d go for subversion  because at that point you need to set up a  dedicated  server or location    You can do this just as well with git as with SVN  but the benefits of git get outweighed by the need to do additional steps to synch with a central server  In SVN you just commit  In git you have to git commit  then git push  The additional step gets annoying simply because you end up doing it so much   SVN also has the benefit of better GUI tools  however the git ecosystem seems to be catching up quickly  so I wouldn t worry about this in the long term

User · Answer

Well  it s distributed  Benchmarks indicate that it s considerably faster  given its distributed nature  operations like diffs and logs are all local so of course it s blazingly faster in this case   and working folders are smaller  which still blows my mind    When you re working on subversion  or any other client server revision control system  you essentially create working copies on your machine by checking-out revisions  This represents a snapshot in time of what the repository looks like  You update your working copy via updates  and you update the repository via commits   With a distributed version control  you don t have a snapshot  but rather the entire codebase  Wanna do a diff with a 3 month old version  No problem  the 3 month old version is still on your computer  This doesn t only mean things are way faster  but if you re disconnected from your central server  you can still do many of the operations you re used to  In other words  you don t just have a snapshot of a given revision  but the entire codebase   You d think that Git would take up a bunch of space on your harddrive  but from a couple benchmarks I ve seen  it actually takes less  Don t ask me how  I mean  it was built by Linus  he knows a thing or two about filesystems I guess

User · Answer

The funny thing is  I host projects in Subversion Repos  but access them via the Git Clone command   Please read Develop with Git on a Google Code Project     Although Google Code natively speaks   Subversion  you can easily use Git   during development  Searching for  git   svn  suggests this practice is   widespread  and we too encourage you   to experiment with it    Using Git on a Svn Repository gives me benefits    I can work distributed on several machines  commiting and pulling from and to them I have a central backup public svn repository for others to check out And they are free to use Git for their own

User · Answer

Git in Windows is quite well supported now   Check out GitExtensions   http   code google com p gitextensions   and the manual for a better Windows Git experience

User · Answer

http   subversion wandisco com component content article 1 40 html  I think it s fairly safe to say that amongst developers  the SVN Vs  Git argument has been raging for some time now  with everyone having their own view on which is better   This was even brought up in the of the questions during our Webinar on Subversion in 2010 and Beyond   Hyrum Wright  our Director of Open Source and the President for the  Subversion Corporation talks about the differences between Subversion and Git  along with other Distributed Version Control Systems  DVCS    He also talks about the upcoming changes in Subversion  such as Working Copy Next Generation  WC-NG   which he believes will cause a number of Git users to convert back to Subversion   Have a watch of his video and let us know what you think by either commenting on this blog  or by posting in our forums   Registration is simple and will only take a moment

User · Answer

Why Git is Better than X  outlines the various pros and cons of Git vs other SCMs   Briefly    Git tracks content rather than files Branches are lightweight and merging is easy  and I mean really easy  It s distributed  basically every repository is a branch  It s much easier to develop concurrently and collaboratively than with Subversion  in my opinion  It also makes offline development possible  It doesn t impose any workflow  as seen on the above linked website  there are many workflows possible with Git  A Subversion-style workflow is easily mimicked  Git repositories are much smaller in file size than Subversion repositories  There s only one   git  directory  as opposed to dozens of   svn  repositories  note Subversion 1 7 and higher now uses a single directory like Git   The staging area is awesome  it allows you to see the changes you will commit  commit partial changes and do various other stuff  Stashing is invaluable when you do  chaotic  development  or simply want to fix a bug while you re still working on something else  on a different branch   You can rewrite history  which is great for preparing patch sets and fixing your mistakes  before you publish the commits      and a lot more    There are some disadvantages    There aren t many good GUIs for it yet  It s new and Subversion has been around for a lot longer  so this is natural as there are a few interfaces in development  Some good ones include TortoiseGit and GitHub for Mac  Partial checkouts clones of repositories are not possible at the moment  I read that it s in development   However  there is submodule support  Git 1 7  supports sparse checkouts  It might be harder to learn  even though I did not find this to be the case  about a year ago   Git has recently improved its interface and is quite user friendly    In the most simplistic usage  Subversion and Git are pretty much the same  There isn t much difference between   svn checkout svn   foo com bar bar cd bar   edit svn commit -m  foo    and  git clone git github com foo bar git cd bar   edit git commit -a -m  foo  git push   Where Git really shines is branching and working with other people

User · Answer

Google Tech Talk  Linus Torvalds on git  http   www youtube com watch v 4XpnKHJAok8  The Git Wiki s comparison page  http   git or cz gitwiki GitSvnComparsion

User · Answer

Easy Git has a nice page comparing actual usage of Git and SVN which will give you an idea of what things Git can do  or do more easily  compared to SVN    Technically  this is based on Easy Git  which is a lightweight wrapper on top of Git

User · Answer

Subversion is very easy to use  I have never found in the last years a problem or that something doesn t work as expected  Also there are many excellent GUI tools and the support for SVN integration is big   With Git you get a more flexible VCS  You can use it the same way like SVN with a remote repository where you commit all changes  But you can also use it mostly offline and only push the changes from time to time to the remote repository  But Git is more complex and has a steeper learning curve  I found myself in the first time committing to wrong branches  creating branches indirectly or get error messages with not much informations about the mistake and where I must search with Google to get better informations  Some easy things like substitution of markers   Id   doesn t work but GIT has a very flexible filtering and hook mechanism to merge own scripts and so you get all things you need and more but it needs more time and reading of the documentation     If you work mostly offline with your local repository you have no backup if something is lost on your local machine  With SVN you are mostly working with a remote repository which is also the same time your backup on another server     Git can work in the same way but this was not the main goal of Linus to have something like SVN2  It was designed for the Linux kernel developers and the needs of a distributed version control system   Is Git better then SVN  Developers which needs only some version history and a backup mechanism have a good and easy life with SVN  Developers working often with branches  testing more versions at the same time or working mostly offline can benefit from the features of Git  There are some very useful features like stashing not found with SVN which can make the life easier  But on the other side not all people will need all features  So I cannot see the dead of SVN   Git needs some better documentation and the error reporting must be more helpful  Also the existing useful GUIs are only rarely  This time I have only found 1 GUI for Linux with support of most Git features  git-cola   Eclipse integration is working but its not official released and there is no official update site  only some external update site with periodical builds from the trunk http   www jgit org updates  So the most preferred way to use Git this days is the command line

User · Answer

I absolutely love being able to manage local branches of my source code in Git without muddying up the water of the central repository   In many cases I ll checkout code from the Subversion server and run a local Git repository just to be able to do this   It s also great that initializing a Git repository doesn t pollute the filesystem with a bunch of annoying  svn folders everywhere   And as far as Windows tool support  TortoiseGit handles the basics very well  but I still prefer the command line unless I want to view the log   I really like the way Tortoise Git SVN  helps when reading commit logs

User · Answer

For people looking for a good Git GUI  Syntevo SmartGit might be a good solution  Its proprietary  but free for non-commercial use  runs on Windows Mac Linux and even supports SVN using some kind of git-svn bridge  I think

User · Answer

A few answers have alluded to these  but I want to make 2 points explicit   1  The ability to do selective commits  for example  git add --patch    If your working directory contains multiple changes that are not part of the same logical change  Git makes it very easy to make a commit that includes only a portion of the changes   With Subversion  it is difficult   2  The ability to commit without making the change public   In Subversion  any commit is immediately public  and thus irrevocable   This greatly limits the ability of the developer to  commit early  commit often    Git is more than just a VCS  it s also a tool for developing patches  Subversion is merely a VCS

User · Answer

Git also makes branching and merging really easy  Subversion 1 5 just added merge tracking  but Git is still better  With Git branching is very fast and cheap  It makes creating a branch for each new feature more feasible  Oh and Git repositories are very efficient with storage space as compared to Subversion

User · Answer

Other answers have done a good job of explaining the core features of Git  which are great   But there s also so many little ways that Git behaves better and helps keep my life more sane  Here are some of the little things    Git has a  clean  command  SVN desperately needs this command  considering how frequently it will dump extra files on your disk  Git has the  bisect  command  It s nice  SVN creates  svn directories in every single folder  Git only creates one  git directory   Every script you write  and every grep you do  will need to be written to ignore these  svn directories  You also need an entire command   svn export   just to get a sane copy of your files  In SVN  each file  amp  folder can come from a different revision or branch  At first  it sounds nice to have this freedom  But what this actually means is that there is a million different ways for your local checkout to be completely screwed up   for example  if  svn switch  fails halfway through  or if you enter a command wrong   And the worst part is  if you ever get into a situation where some of your files are coming from one place  and some of them from another  the  svn status  will tell you that everything is normal  You ll need to do  svn info  on each file directory to discover how weird things are  If  git status  tells you that things are normal  then you can trust that things really are normal  You have to tell SVN whenever you move or delete something  Git will just figure it out  Ignore semantics are easier in Git  If you ignore a pattern  such as   pyc   it will be ignored for all subdirectories   But if you really want to ignore something for just one directory  you can   With SVN  it seems that there is no easy way to ignore a pattern across all subdirectories  Another item involving ignore files  Git makes it possible to have  private  ignore settings  using the file  git info exclude   which won t affect anyone else

User · Answer

This is the wrong question to be asking   It s all too easy to focus on git s warts and formulate an argument about why subversion is ostensibly better  at least for some use cases   The fact that git was originally designed as a low-level version control construction set and has a baroque linux-developer-oriented interface makes it easier for the holy wars to gain traction and perceived legitimacy   Git proponents bang the drum with millions of workflow advantages  which svn guys proclaim unnecessary   Pretty soon the whole debate is framed as centralized vs distributed  which serves the interests of the enterprise svn tool community   These companies  which typically put out the most convincing articles about subversion s superiority in the enterprise  are dependent on the perceived insecurity of git and the enterprise-readiness of svn for the long-term success of their products   But here s the problem  Subversion is an architectural dead-end     Whereas you can take git and build a centralized subversion replacement quite easily  despite being around for more than twice as long svn has never been able to get even basic merge-tracking working anywhere near as well as it does in git   One basic reason for this is the design decision to make branches the same as directories   I don t know why they went this way originally  it certainly makes partial checkouts very simple   Unfortunately it also makes it impossible to track history properly   Now obviously you are supposed to use subversion repository layout conventions to separate branches from regular directories  and svn uses some heuristics to make things work for the daily use cases   But all this is just papering over a very poor and limiting low-level design decision   Being able to a do a repository-wise diff  rather than directory-wise diff  is basic and critical functionality for a version control system  and greatly simplifies the internals  making it possible to build smarter and useful features on top of it   You can see in the amount of effort that has been put into extending subversion  and yet how far behind it is from the current crop of modern VCSes in terms of fundamental operations like merge resolution   Now here s my heart-felt and agnostic advice for anyone who still believes Subversion is good enough for the foreseeable future   Subversion will never catch up to the newer breeds of VCSes that have learned from the mistakes of RCS and CVS  it is a technical impossibility unless they retool the repository model from the ground up  but then it wouldn t really be svn would it   Regardless of how much you think you don t the capabilities of a modern VCS  your ignorance will not protect you from the Subversion s pitfalls  many of which are situations that are impossible or easily resolved in other systems   It is extremely rare that the technical inferiority of a solution is so clear-cut as it is with svn  certainly I would never state such an opinion about win-vs-linux or emacs-vs-vi  but in this case it is so clearcut  and source control is such a fundamental tool in the developer s arsenal  that I feel it must be stated unequivocally   Regardless of the requirement to use svn for organizational reasons  I implore all svn users not to let their logical mind construct a false belief that more modern VCSes are only useful for large open-source projects   Regardless of the nature of your development work  if you are a programmer  you will be a more effective programmer if you learn how to use better-designed VCSes  whether it be Git  Mercurial  Darcs  or many others

User · Answer

Subversion is still a much more used version control system  which means that it has better tool support   You ll find mature SVN plugins for almost any IDE  and there are good explorer extensions available  like TurtoiseSVN    Other than that  I ll have to agree with Michael   Git isn t better or worse than Subversion  it s different

User · Answer

Git is not better than Subversion  But is also not worse  It s different   The key difference is that it is decentralized  Imagine you are a developer on the road  you develop on your laptop and you want to have source control so that you can go back 3 hours   With Subversion  you have a Problem  The SVN Repository may be in a location you can t reach  in your company  and you don t have internet at the moment   you cannot commit  If you want to make a copy of your code  you have to literally copy paste it   With Git  you do not have this problem  Your local copy is a repository  and you can commit to it and get all benefits of source control  When you regain connectivity to the main repository  you can commit against it   This looks good at first  but just keep in mind the added complexity to this approach   Git seems to be the  new  shiny  cool  thing  It s by no means bad  there is a reason Linus wrote it for the Linux Kernel development after all   but I feel that many people jump on the  Distributed Source Control  train just because it s new and is written by Linus Torvalds  without actually knowing why if it s better   Subversion has Problems  but so does Git  Mercurial  CVS  TFS or whatever   Edit  So this answer is now a year old and still generates many upvotes  so I thought I ll add some more explanations  In the last year since writing this  Git has gained a lot of momentum and support  particularly since sites like GitHub really took off  I m using both Git and Subversion nowadays and I d like to share some personal insight   First of all  Git can be really confusing at first when working decentralized  What is a remote  and How to properly set up the initial repository  are two questions that come up at the beginning  especially compared to SVN s simple  svnadmin create   Git s  git init  can take the parameters --bare and --shared which seems to be the  proper  way to set up a centralized repository  There are reasons for this  but it adds complexity  The documentation of the  checkout  command is very confusing to people changing over - the  proper  way seems to be  git clone   while  git checkout  seems to switch branches   Git REALLY shines when you are decentralized  I have a server at home and a Laptop on the road  and SVN simply doesn t work well here  With SVN  I can t have local source control if I m not connected to the repository  Yes  I know about SVK or about ways to copy the repo   With Git  that s the default mode anyway  It s an extra command though  git commit commits locally  whereas git push origin master pushes the master branch to the remote named  origin     As said above  Git adds complexity  Two modes of creating repositories  checkout vs  clone  commit vs  push    You have to know which commands work locally and which work with  the server   I m assuming most people still like a central  master-repository     Also  the tooling is still insufficient  at least on Windows  Yes  there is a Visual Studio AddIn  but I still use git bash with msysgit   SVN has the advantage that it s MUCH simpler to learn  There is your repository  all changes to towards it  if you know how to create  commit and checkout and you re ready to go and can pickup stuff like branching  update etc  later on   Git has the advantage that it s MUCH better suited if some developers are not always connected to the master repository  Also  it s much faster than SVN  And from what I hear  branching and merging support is a lot better  which is to be expected  as these are the core reasons it was written    This also explains why it gains so much buzz on the Internet  as Git is perfectly suited for Open Source projects  Just Fork it  commit your changes to your own Fork  and then ask the original project maintainer to pull your changes  With Git  this just works  Really  try it on Github  it s magic   What I also see are Git-SVN Bridges  The central repository is a Subversion repo  but developers locally work with Git and the bridge then pushes their changes to SVN   But even with this lengthy addition  I still stand by my core message  Git is not better or worse  it s just different  If you have the need for  Offline Source Control  and the willingness to spend some extra time learning it  it s fantastic  But if you have a strictly centralized Source Control and or are struggling to introduce Source Control in the first place because your co-workers are not interested  then the simplicity and excellent tooling  at least on Windows  of SVN shine

User · Answer

The main points I like about DVCS are those     You can commit broken things  It doesn t matter because other peoples won t see them until you publish  Publish time is different of commit time  Because of this you can commit more often  You can merge complete functionnality  This functionnality will have its own branch  All commits of this branch will be related to this functionnality  You can do it with a CVCS however with DVCS its the default  You can search your history  find when a function changed   You can undo a pull if someone screw up the main repository  you don t need to fix the errors  Just clear the merge  When you need a source control in any directory do   git init   and you can commit  undoing changes  etc    It s fast  even on Windows     The main reason for a relatively big project is the improved communication created by the point 3  Others are nice bonuses

User · Answer

I like Git because it actually helps communication developer to developer on a medium to large team  As a distributed version control system  through its push pull system  it helps developers to create a source code eco-system which helps to manage a large pool of developers working on a single project   For example say you trust 5 developers and only pull codes from their repository  Each of those developers has their own trust network from where they pull codes  Thus the development is based on that trust fabric of developers where code responsibility is shared among the development community   Of course there are other benefits which are mentioned in other answers here

User · Answer

Eric Sink from SourceGear wrote series of articles on differences between distributed and nondistributed version controls systems  He compares pros and cons of most popular version control systems  Very interesting reading   Articles can be found on his blog  www ericsink com    Read the Diffs Git is the C of Version Control Tools On Git s lack of respect for immutability and the Best Practices for a DVCS DVCS and DAGs  Part 1 DVCS and DAGs  Part 2 DVCS and Bug Tracking Merge History  DAGs and Darcs Why is Git so Fast  Mercurial  Subversion  and Wesley Snipes

User · Answer

All the answers here are as expected  programmer centric  however what happens if your company uses revision control outside of source code  There are plenty of documents which aren t source code which benefit from version control  and should live close to code and not in another CMS  Most programmers don t work in isolation - we work for companies as part of a team   With that in mind  compare ease of use  in both client tooling and training  between Subversion and git  I can t see a scenario where any distributed revision control system is going to be easier to use or explain to a non-programmer  I d love to be proven wrong  because then I d be able to evaluate git and actually have a hope of it being accepted by people who need version control who aren t programmers   Even then  if asked by management why we should move from a centralised to distributed  revision control system  I d be hard pressed to give an honest answer  because we don t need it   Disclaimer  I became interested in Subversion early on  around v0 29  so obviously I m biased  but the companies I ve worked for since that time are benefiting from my enthusiasm because I ve encouraged and supported its use  I suspect this is how it happens with most software companies   With so many programmers jumping on the git bandwagon  I wonder how many companies are going to miss out on the benefits of using version control outside of source code  Even if you have separate systems for different teams  you re missing out on some of the benefits  such as  unified  issue tracking integration  whilst increasing maintenance  hardware and training requirements

User · Answer

Git and DVCS in general is great for developers doing a lot of coding independently of each other because everyone has their own branch   If you need a change from someone else  though  she has to commit to her local repo and then she must push that changeset to you or you must pull it from her   My own reasoning also makes me think DVCS makes things harder for QA and release management if you do things like centralized releases   Someone has to be responsible for doing that push pull from everyone else s repository  resolving any conflicts that would have been resolved at initial commit time before  then doing the build  and then having all the other developers re-sync their repos   All of this can be addressed with human processes  of course  DVCS just broke something that was fixed by centralized version control in order to provide some new conveniences

User · Answer

Thanks to the fact it doesn t need to communicate with a central server constantly  pretty much every command runs in less than a second  obviously git push pull fetch are slower simply because they have to initalise SSH connections   Branching is far far easier  one simple command to branch  one simple command to merge

User · Answer

With Git  you can do practically anything offline  because everybody has their own repository   Making branches and merging between branches is really easy   Even if you don t have commit rights for a project  you can still have your own repository online  and publish  push requests  for your patches  Everybody who likes your patches can pull them into their project  including the official maintainers   It s trivial to fork a project  modify it  and still keep merging in the bugfixes from the HEAD branch    Git works for the Linux kernel developers  That means it is really fast  it has to be   and scales to thousands of contributors  Git also uses less space  up to 30 times less space for the Mozilla repository    Git is very flexible  very TIMTOWTDI  There is more than one way to do it   You can use whatever workflow you want  and Git will support it   Finally  there s GitHub  a great site for hosting your Git repositories   Drawbacks of Git     it s much harder to learn  because Git has more concepts and more commands  revisions don t have version numbers like in subversion many Git commands are cryptic  and error messages are very user-unfriendly it lacks a good GUI  such as the great TortoiseSVN

User · Answer

I have been dwelling in Git land lately  and I like it for personal projects  but I wouldn t be able to switch work projects to it yet from Subversion given the change in thinking of required from staff  without no pressing benefits  Moreover the biggest project we run in-house is extremely dependent on svn externals which  from what I ve seen so far  does not work so nicely and seamlessly in Git

User · Answer

I think Subversion is fine   until you start merging   or doing anything complicated   or doing anything Subversion thinks is complicated  like doing queries to find out which branches messed with a particular file  where a change actually comes from  detecting copy amp pastes  etc      I disagree with the winning answer  saying the main benefit of GIT is offline work - it s certainly useful  but it s more like an extra for my use case  SVK can work offline too  still there is no question for me which one to invest my learning time in    It s just that it s incredibly powerful and fast and  well -after getting used to the concepts - very useful  yes  in that sense  user friendly    For more details on a merging story  see this   Using git-svn  or similar   just  to help out with an svn merge

User · Answer

One of the things about SubVersion that irks me is that it puts its own folder in each directory of a project  whereas git only puts one in the root directory  It s not that big of a deal  but little things like that add up   Of course  SubVersion has Tortoise  which is  usually  very nice

User · Answer

David Richards WANdisco Blog on Subversion   GIT     The emergence of GIT  has brought with it a breed of DVCS fundamentalists     the    Gitterons        that think anything other than GIT is crap  The Gitterons seem to think software engineering happens on their own island and often forget that most organizations don   t employ senior software engineers exclusively  That   s ok but it   s not how the rest of the market thinks  and I am happy to prove it  GIT  at the last look had less than three per cent of the market while Subversion has in the region of five million users and about half of the overall market       The problem we saw was that the Gitterons were firing  cheap  shots at Subversion  Tweets like    Subversion is so  slow crappy restrictive doesn t smell good looks at me in a funny way  and now I have GIT and  everything works in my life my wife got pregnant I got a girlfriend after 30 years of trying I won six times running on the blackjack table   You get the picture

User · Answer

First  concurrent version control seems like an easy problem to solve  It s not at all  Anyway     SVN is quite non-intuitive  Git is even worse   sarcastic-speculation  This might be because developers  that like hard problems like concurrent version control  don t have much interest in making a good UI    sarcastic-speculation   SVN supporters think they don t need a distributed version-control system  I thought that too  But now that we use Git exclusively  I m a believer  Now version control works for me AND the team project instead of just working for the project  When I need a branch  I branch  Sometimes it s a branch that has a corresponding branch on the server  and sometimes it does not  Not to mention all the other advantages that I ll have to go study up on  thanks in part to the arcane and absurd lack of UI that is a modern version control system

User · Answer

Why I think Subversion is better than Git  at least for the projects I work on   mainly due to its usability  and simpler workflow   http   www databasesandlife com why-subversion-is-better-than-git

[svn] Why is Git better than Subversion?

Examples related to svn

Examples related to git