Version control enables you to keep track of all the versions of your projects and code changes. It maintains a repository of your project files together with all the changes and amendments made to these files. This, in turn, enables anybody working with the project to access the changes, who made them and why. It is essential that developers have access to this information.
There are two major version control repositories: Git and SVN, each being free software distributed under the GNU General Public License. SVN is short for Apache Subversion while Git is just that. There are differences between the two that attract their own adherents, though many ways towards Git because of the control they have over the repositories they are working with. More on this shortly.
Contents
The Need for Version Control
Within a team of developers, each individual must be able to access the current version of a project. They must also be able to work on that version individually; the code is not a library book that can be borrowed, changed and then put back again. Each team member must have access when needed, and not wait for the code to be returned before they can see the latest version.
A major problem with two developers working on the same project at the same time is that each subsequent developer will save the project and so override all the changes made previously with no record of them. Version control permits developers to access a project and work on it while others are doing the same. Once they have completed their work, it will be sent back to the repository with the changes merged into version control.
What this means is there is a copy of every version available to developers. Should a change fail to operate as it should, you simply go back to the previous version and start again. You do not have to access all your changes and remove them to get back to the previous state of development. Code history is essential, and without version control, there would be none.
Blame Feature
The blame feature refers to one developer, say you, finding out why a particular code change has been made. Using version control you can establish the author of that change and ask for the reasoning. This may be for educational reasons, or to establish who needs retraining!
Given that explanation of version control, which is better: Git or SVN? There are others, but these are the two most popular repositories. Here is how each works:
SVN (Apache Subversion)
SVN is fairly simple to use. If you use WordPress, this is the plugin you will probably be using. Your repository comes in the form of a central server with three fundamental areas: the Trunk, Branches and Tags.
The Trunk
The trunk is where you should keep your stable code. You should never send any experimental unproved code here because this is where other developers working on the same project will access workable updates. The only changes to be merged into the trunk should be finished coding.
Branches
When you are working on new developments, you do not add them to the trunk, as explained above, but should branch the code out. What you do is to store a copy of the trunk as it is when you start into a folder in the ‘branch’ area. You can then work on it from there, and merge it back to the trunk only when your coding is complete.
What this means is that you can carry on with your development in your own space without disrupting any of the coding already complete. Others can do the same, keeping the trunk intact until permanent changes have been proved.
Tags
As the term suggests, you use this to tag your code. It is simply a copy of your current code placed into a tag folder that you can use to get back to your project as it was when you tagged it. You don’t use a tag to work o – it’s simply a bookmark of where you were at that specific time in case you have to backtrack.
Tags are generally used when the code is ready to be deployed. Once it has been completed and merged into the trunk, tested, it will be tested – then you would tag the trunk. Just before release. Then you release the development to your live server. If the release fails to operate as intended, you can then mark that tag as broken and revert to your previous tag to resolve the issue.
How GIT Works
The main difference between Git and SVN is that the former has a number of repositories, compared to the one of SVN. With Git, there is a central repository, but there are also individual repositories for each developer.
What this allows, is for developers to work in their repository if the central one fails. The problem with SVN is that in the event of repository failure, nobody can commit any code until it has been repaired. Not so with Git. There is no such hold-up, and everybody can continue their work until the central depository is back to normal – then they can deploy their code into it.
Git Individual Repositories
Individual repositories are quick and permit developers to work by themselves until they are ready to deploy their code.
- First, you clone the master repository, creating a local repository on your own computer.
- You can then work on this.
- If the code proves to operate fine in the clone, you can then push the changes back to the master repository. If not, you have not harmed the master.
In step 1, you can work fundamentally as you would with SVN: creating branches and tags using the cloned master as the trunk. Developers prefer Git because they each have their own repository to work with, and have no need to commit any code until they have tested it fully in their clone.
Another benefit of Git that many like is that they have no need to be connected online. They can store the clone master repository on their computer and work from there. They can, therefore, work on projects without the need to seek a connection or wireless hotspot.
SEE ALSO: How to Use Git on Windows?.
Public and Private Repositories
Git enables you to have public and private local repositories. Other developers can pull changes from your local repositories; hence the need for a private repository to prevent that from happening. You can also push changes from your public repository over SSH. It is largely because of the ability of Git to enable you to use cloned and local repositories that many developers prefer it to SVN.
Forking Repo: When to Use It
“Forking repo” is used when you want to add a contribution to somebody else’s project or use their project as a start for your own. When you fork, you essentially create a clone of the repository along with its history, to which you can commit your own work.
If you use the fork-and-pull model of open source development, it is possible for you to begin to make alterations without requesting permission of the project owners. If you want to contribute your work back, you can send a ‘pull request’ from the forked repo to the original repo.
To create a fork, first, locate the repository to be forked. To do this you can use the ‘search’ facility on the Bitbucket menu bar. Go to the repository and then click the ‘Fork’ button. You will then see the Fork options which you should define. These include options such as Owner, Description, Permissions, etc.
Once you have completed these, click on Fork Repository and you can continue working on the fork. Once you have made your necessary commits, you can push them back into the forked project in the same as you would with a regular repository. You can also pull in upstream changes to the original repository using the code:
[html] git fetch upstreamgit merge upstream/master
[/html]
This pulls changes made to the original after you cloned it into your clone and, you can then continue working on the latest version of the repository.
You must make your own decision on which version control repository suits you best. In some cases, over-complication of version control can be confusing, but it is important that you are aware of what is available to you. Which version control repository you’re using, which one you feel better, share your thoughts in form of comments below.
