What is the difference, really? When should you pick which? The main and perhaps best-known difference is in its core architecture. Git version control is distributed while SVN is centralized. Other variations in approach and functionality between the two are important to understand if you want to use either effectively.
The general sentiment on the web leans toward Git as their go-to solution for version control in their projects. This is precisely the reason we picked to focus on the advantage of SVN over Git first. One thing that can be said in favor of centralized version control architecture like SVN is that it is efficient in handling network traffic and assuring synchronization between teams and developers.
When you work with SVN you only need to synchronize the differences between what you have locally and the latest on the server. This is much faster than with Git. Due to it being distributed, you have to download all changes, even if those changes add gigabytes of useless assets that have since been deleted from the branch. Perhaps the most inarguable advantage SVN has over Git is in how it handles binary files.
The reason for this superiority is the support Subversion provides for the Lock-Modify-Unlock model. It is implemented in SVN using a lock command svn:needs-lock property while Git offers no exclusive file locking at all due to its distributed nature.
Obviously, all the above arguments are valid but they are not really convincing enough to persuade anyone to replace SVN with Git. Imagine a conversation between a Git fan and a SVN user:. SVN is fast enough for me. I commit once a day, that takes a few seconds, so no problem at all…. Developers can commit their changes directly to that central server repository. Then you work on your feature. The benefit of branching is the ability to make commits into the branch without breaking the trunk.
You only merge into the trunk when your code is error-free. This keeps your trunk stable. And users generally appreciate how easy it is to use and understand SVN. However, working on one central server means there is a single point of failure. If there is an error, it can destroy all builds.
Limited offline access is also a frequent point of complaint. While centralized systems were the version control system of choice for nearly a decade, Git has surpassed them in recent years. Unlike SVN, Git utilizes multiple repositories: a central repository and a series of local repositories.
Local repositories are exact copies of the central repository complete with the entire history of changes. Then you work on your local repository exactly as you would in SVN by creating new branches, tags, etc.
That means that support is available for all platforms, multiple sets of technologies, languages, and frameworks. There is one con teams find frustrating: the ever-growing complexity of history logs.
Because developers take extra steps when merging, history logs of each issue can become dense and difficult to decipher. This can potentially make analyzing your system harder. Although similar in name, Git and GitHub offer very different services.
While Git allows users to make edits and make changes to and track their repository of code, GitHub is a cloud-based host that allows you to upload and manage Git repositories in an open-source format. By managing a project in GitHub, all of your team can make edits simultaneously without affecting the trunk. Treehouse writes on August 7, You may have heard some hubbub over distributed version control systems recently.
You may dismiss it as the next hot thing, the newest flavor of kool-aid currently quenching the collective thirst of the bandwagon jumpers. You, however, have been using Subversion quite happily for some time now. You may want to give it a second look.
Not just at distributed version control systems, but at the real role of version control in your creative toolkit. To learn Git, there is a free online book called Pro Git that I wrote that will walk you through Git step by step, should this article entice you.
For each point I make here, I will be linking to the appropriate section of that book, should you want to find out more about that specific feature of Git. These are things that systems like Subversion simply cannot do. These tools should completely change the way you work and the way you think about working. Git is a distributed version control system.
This means that immediately after the clone, there is basically no information about that project that the server you cloned from has that you do not have. Now, this gives you a couple of immediate advantages. One is that nearly every operation is now done off data on your local disk, meaning that it is both unbeliveably fast and can be done offline. This means that you can do commits, diffs, logs, branches, merges, file annotation and more — entirely offline, off VPN and generally instantly.
Most commands you run in Git take longer to type then they do to execute. The other implicit advantage of this model is that your workflow does not have a single point of failure. Since every person working on your project has what is essentially a full backup of the project data, losing your collaboration servers is a minor inconvenience at best. Imagine for a moment your SVN server having a hard drive corruption — when was your last backup and how many hours will it take to get to the point where your team can start working again?
In Git, any team member can push to any server where every member has SSH access and the whole team can be easily up and running in a matter of minutes.
Git does not depend on a centralized server, but does have the ability to syncronize with other Git repositories — to push and pull changes between them. This means that you can add multiple remote repositories to your project, some read-only and some possibly with write access as well, meaning you can have nearly any type of workflow you can think of.
You can continue to use a centralized workflow, with one central server that everyone pushes to and pulls from. However, you can also do more interesting things. You can build any sort of heirarchical or peer-based workflow model with Git that you can think of, in addition to being able to use it as a centralized hub as in SVN.
Your workflow can grow and adapt with your business model. You can also use it in other ways — an interesting example of this is deploying on the Ruby hosting company Heroku. You can develop and collaborate on other remote repositories, but then when you actually want to deploy your code to running servers, you push to the Heroku Git repository instead. Imagine trying to do that with Subversion.
Before I begin explaining this, which is actually my favorite feature of Git, I need you to do me a favor. Forget everthing you know about branches. Forget how painful it was to merge, forget how long it took to switch branches, forget how impossible it was to merge from a branch more than once — Git gives you a whole new world when it comes to branching and merging.
This is what hooked me on Git in the first place, and in fact has changed the entire way I approach my development. When you create a branch in Git, it does so locally and it happens very fast. Here is an example of creating a branch and then switching to your new branch to start doing development.
It took about a third of a second for both commands together. Also, branching is considered a fast operation in Subversion — you will see even more pronounced speed differences in other common operations like log and diff.
However, that is not the real power of Git branches. The real power is how you use them, the raw speed and ease of the commands just makes it more likely that you will. In Git, a common use case is to create a new local branch for everything you work on. Each feature, each idea, each bugfix — you can easily create a new branch quickly, do a few commits on that branch and then either merge it into your mainline work or throw it away.
Now, once you have work on a couple of branches, what about merging? Most Subversion users are used to having to figure that out manually, which is an error prone and time consuming process — Git makes it trivial. Furthermore, you can merge from the same branch multiple times and not have to resolve the same conflicts over and over again. As an anecdotal case study, take my Pro Git book. I put the Markdown source of the book on GitHub , the social code hosting site that I work for.
Within a few days, I started getting dozens of people forking my project and contributing. In Git, each of these forks is treated as a branch which I could pull down and merge individually.
I spend a few minutes once or twice a week to pull down all the work that has happened, inspect each branch and merge the approved ones into my mainline. As an example, during the last merge session I inspected and merged 5 seperate branches in 13 minutes.
0コメント