For those never been involved in the development, it is quite strange to hear of a version control systems, or simply VCS. Of course, there are many of VCS’s, they work quite alike, but they are different, eventually. There are more than forty of them, and the actual purpose of each one is to allow a group of developers to work on the project without breaking it.
Without a version control system, the cooperation between the team members would look something like this: a bunch of developers working on the project, and blindly overwriting each other’s changes. So that, VCS, first of all, allows viewing of all the changes made during the development process. It gives you an opportunity to let your team work freely in any folder and file, without risking to do a work of Sisyphus. That is made by creating different versions of each file or the whole project, and also saving the source. All those changes are to be merged later in a single working version.
Version control system and its types
All the VCSs can be divided into centralized and distributed. Centralized version control systems use one main server to save all the changes. Distributed, allow each member of a team to store a local copy of the entire project with all the changes. The difference sounds pretty small, but those are two completely diverse approaches, which have their pros and cons. Roughly speaking, centralized systems give you more control over the folder access and organization, more reliable and constant backups. In the opposite, distributed systems go for a quick and simple merging, more flexible for any single project’s and team’s workflow.
As you can see, VCSs store a lot of data about the project’s inner processes. It varies how two systems store the information, for example, Visual Studio Team services by Microsoft and Subversion by CollabNet.inc. But, today we are going to talk about one exact VCS, that we consider the best one — Git.
Git and its features
Git is a free and open-source version control system, that was created in 2005 by Linus Torvalds, the creator of Linux UNIX based operating systems. One may wonder what does the “Git” abbreviation stand for? Or, is it even an abbreviation? The answer can be found on the Git FAQ page, where Torvalds himself gives the answer. And the most civil one is: “Random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of “get” may or may not be relevant.”
Many people confuse Git with a website Github.com, which is a platform for hosting projects that use Git. Other common misconception about Git, is that it is a VCS for newbies, because of its features and easiness in mastering. Nevertheless, “easy to master” doesn’t mean “a toy for a rookie”.
Git falls under the category of distributed version control systems, which can be simply named as DVCS. So, as we mentioned before, Git, being a DVCS, allows users to get a copy of an entire history of the project in one click. To be precise, making a copy from a Git repository, is as fast, as checking a single version of the repository on the centralized VCS.
That guides us to the first important Git feature. Having a copy of the project on your local storage, you may work on it offline, making logs, merges, creating branches. Moreover, thanks to the data situated on the local hardware, you don’t need to sync with some cloud storage or remote machine. That means, no more waiting. Git is really fast in performing any commands so that it takes longer to type and click than waiting for the Git to finish the process.
Safety
Data preservation is also good, at the point. Considering the fact, that every person working on the project has a separate copy with a full history of commits, a risk to lose all the data because server crash or any other malfunction is minimal.
If it ever happens for your server hard drive to corrupt, any of your team members may push the latest version of the project preserved.
Flexibility
One more brilliant thing Git enables the user to do is using a flexible workflow. In the most basic variant, the development process is divided into several branches, where some fundamental changes are made, then all together they are merged into a production branch and that’s it. In Git you are able to create subbranches and repositories for, for example, every single developer and designer. The beautiful thing is that a merge between the team may happen in any order. That means, your “imagined” QA team may pull all the changes from “developers” repository (or multiple repositories for each developer), and then push it to the “production” repository. Impressive, isn’t it?
In Git it is very common practice to create new branches for any new feature you can work on. Despite the fact that they are created really fast and easy, it allows to save time and organize the data.
Git uses a push&pull concept to merge the branches. There are some advantages to it and some disadvantages. First of all, a pull function allows getting the latest version from a master branch. A push version allows uploading new features and files to the branch. When you need to get the changes from a branch, but don’t merge it with yours, there is also a fetch function. In a nutshell, fetch is used to load the data on your local storage without making changes to your files.
Sometimes you may experience a merge conflict if somebody makes changes to the master branch, while you were working on your local copy. The problem is pretty well-known and may be solved in two variants:
- Create new branches for every feature you work on.
- Pull the master branch and fix the merge conflict.
Diversity for all
Not only developer-wise but also project manager-wise and client-wise also, Git gives an opportunity to present the work well-structured with the help of the “staging area”. So, the staging area is a tool, or better to say, a feature, which helps to create logically separated commits. Let’s imagine that one of our developers pushed a pack of fixes in numerous files. In systems like Subversion, it would look like a giant slab of changes, without any logical structure and separation. Staging area allows cutting a slab into several organized commits, structured by the feature or files. That makes a bit easier for the project manager and the client to observe what was done in a visual manner.
Our development team in CrispWP, uses Git for every project. Git allows avoiding version conflicts, keeping the website’s production version safe and clean. All the changes made to the code are pushed to the master branch, according to our internal process. From that point, they go to the server with a development version via auto-deployment. When a new feature is ready, it can be pushed to the special production branch, that can be deployed to a production server. But, in the process of development, the branch remains untouched, so that the whole team can indicate the current version of the production.
Choosing a software to work on, it is always important to consider such factors as the popularity of the software and the community of it. Fortunately, Git is completely okay with that, meaning you are always able to find the answer of how to fix this or that. The community is really huge, a bunch of discussions covering basic and advanced issues can be found on various forums. Or, you can apply your question by email here.