Subversion solves our software versioning problem by providing tools for conflict resolution when doing collaborative work on the same files and projects. We use it with TortoiseSVN and it works great for some of our projects with smaller teams. However, we have a need to make code reviews more and it is a little more difficult to do that in SVN, compared to Bitbucket and Git.
Git is by far the best Source Control Management Tool I've used. I would recommend it to anyone, whether it's an individual working on their own project, a small start-up company, or a huge organization with thousands of developers. Maintaining code via source control is absolutely mandatory for all developers everywhere.
Git is designed to work in a distributed manner, allowing each developer to run a local node that has full control of the project. Through this, the developer is able to merge his work with others on a main 'branch' & work in sync without having to worry about stepping on your other developers toes.
Because Git has solved the software problem of dependency, users who commit code that needs to be deleted can just roll back to a restore point, saving precious development time & tons of headaches for Information Technology. This is also very helpful when cloning projects or creating new features on the current project.
Git has a beautiful command line interface that is intuitive, easy to learn & extensible. You can also observe all the changes you have made in your project throughout the development with just a few simple commands. This diverse set of command-line tools is easy for the end user & very powerful.
Refactoring the layout of a respoitory--or a part of a repository--can be a bit painful, especially for users with workspaces associated with the affected part of the repository. Not sure what could be done to make that better, but it would be nice if something was possible.
Folks coming from Git can have problems using Subversion. Again, not sure anything can (or should) be done to address that, but it is occasionally an issue.
Some of the commands are a little obtuse if you're not using a Git Client
Since Git is so widely used in the development space, it's easy to believe that growth and innovation might become stale in the area of version control. Competition is sparse these days and I'm curious if this "Standard" is going to keep moving forward somehow.
It's hard to fault a tool that is so ubiquitous and hardly gets in your way.
While there are interesting alternatives, such a GIT, Subversion has been a breath of fresh air compared to its predecessors like CVS or Microsoft Source Safe (now called Team Foundation Server). Its ease of use and high adoption rate is going to keep me using this product for years to come.
Git has met all standards for a source control tool and even exceeded those standards. Git is so integrated with our work that I can't imagine a day without it.
I am not sure what the official Git support channels are like as I have never needed to use any official support. Because Git is so popular among all developers now, it is pretty easy to find the answer to almost any Git question with a quick Google search. I've never had trouble finding what I'm looking for.
After Microsoft Visual SourceSafe was discontinued, we chose Subversion and it was a great choice. We were able to migrate to Apache Subversion very quickly and easily and benefited immediately from its non-locking workflow (SourceSafe required users to "lock" the file when editing to prevent editing conflicts from other users, whereas Subversion allows multiple users to edit the same file simultaneously and then merge conflicts later.)
While we still use Apache Subversion for our legacy projects, we've migrated to Git and GitHub for our new projects as that is the new "cool kid" and it provides some benefits such as distributed and offline development. But Git is more complex than Apache Subversion and not as easy to learn.
GIT being a widely used tool have better reliability than its peers and have stands out when we compare it on operational performance criteria. GIT with speedy and extensive branching capabilities have helped developers to use check in their code quickly and space efficient way. GIT have the facility to quickly fetch the complete repository on to your local system.
It allowed us to deliver the right files to our customer without "clobbering" previous releases, making for a far more satisfied customer.
It allowed our developers to work on two releases in parallel (plus an occasional third, for emergency fixes).
With some simple hooks, it allowed us to set up a system where code was was automatically deployed to test servers as soon as developers committed it, making testing easier. This was made easier by virtue of being a ColdFusion project, which requires no compilation. However, that is possible for compiled code with a continuous integration system like Jenkins.
Git has saved our organization countless hours having to manually trace code to a breaking change or manage conflicting changes. It has no equal when it comes to scalability or manageability.
Git has allowed our engineering team to build code reviews into its workflow by preventing a developer from approving or merging in their own code; instead, all proposed changes are reviewed by another engineer to assess the impact of the code and whether or not it should be merged in first. This greatly reduces the likelihood of breaking changes getting into production.
Git has at times created some confusion among developers about what to do if they accidentally commit a change they decide later they want to roll back. There are multiple ways to address this problem and the best available option may not be obvious in all cases.
