Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in any book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer. Below are just some of the benefits you get from using version control-
- Track changes to your code base (i.e. who changed what), and roll back to previous revisions
- Collaborate with your teammates by having the version control system merge your changes with changes made by other developers on the same file(s)
- Create branches of your code, allowing you to maintain different versions of your project in parallel
You can use subversion directly from the command line, but there are also GUIs and IDE plugins that make subversion integration easier.
Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system distributed as open source under the Apache License. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation.
Git is a distributed version control system, it can be used as a server out of the box. Dedicated Git server software helps, amongst other features, to add access control, display the contents of a Git repository via the web, and help managing multiple repositories.
Differences between Git and SVN
In short, svn is a Centralized Revision Control System, and git is a Distributed Revision Control System (DVCS).
When you “check in” or “commit” to svn, you’re contacting a central repository, synchronizing (merging & resolving) with the centralized versions, creating a changelist, and then sending that changelist back to the centralized repository. All users use and share the same repository, possibly with branching. If 2 users want to share code, the only way they can do so is by checking into the repository and then each doing a sync.
In git, when you check out a repository, you’re getting a complete clone of the whole thing – all revisions of all files, all the metadata, everything. You make changes locally, check in (commit) to your local copy of the repository, and then “push” those changesets to another repository when you want to publish them or share them with other users. You can also “pull” to synchronize with a remote repository. Since every repository is equal (they’re all complete copies) you can “push” changes anywhere – this is how 2 or more users can collaborate on a new feature without impacting the centralized repository. These users just issue push/pull operations with each other when they want to share code. Once they have a working functional improvement, they can then “push” all the relevant changesets back to the central or production repository.
Git is very flexible in the workflows that it supports, and many large projects use complex workflows with multiple repositories and gatekeepers. The best way to learn about this is to take a look at this great online reference to git: http://progit.org/book/ch1-1.html