Version control systems (VCS) are blessings to developers like me who work on single project with other developers. Too often someone would accidentally overwrite another’s code, possibly erasing hours of hard work. Some yelling and cursing may ensue, and rifts between teammates develop. Then it leads to people being excluded from team lunches, and April fools pranks get a little more malicious.… ok, maybe I’m dramatizing a bit here, but the point is that when you have multiple working on the same code, accidents tend to happen.
When used correctly, VCS is a great tool that prevents the above scenario from happening. Essentially, every code change is versioned and logged through the system: if there are any mistakes, it is a trivial matter to roll back to a previous version of the file. And, if you are working on the same file with someone else, most if not all VCS handle the merging of changes made to the same file, instead of just overwriting the file. So no one’s work is lost, everyone is included in the lunch invites, and pranks are still good natured enough that no one’s feelings get hurt.
GIT
There are a lot of options when it comes to selecting a VCS. Just about all of them do the same basic functions, and the differences between each are often more an academic than a practical matter for someone like me. Git is the one Web Services ended up using for our team. It is the new hotness of the VCS world, and has a big community behind it. There are numerous documentations on how to use it, but it is fresh enough that people are still discovering new ways of using it. In some ways, it is like a new toy that that just got released, and everyone is learning new ways to play with it.
Git is considered a distributed VCS. That means by default, there is no central official project repository – i.e., there is no “main” copy of the project. Everyone’s copy of the repository is as official as the next person’s. While there are certainly plenty of benefits to this model(being able to commit without network access, allow for private branches that can be pushed out only on completion of new features, etc…), it doesn’t really fit into our development team’s workflow. Luckily Git is flexible enough that we can easily create a centralized setup so we have one canonical copy of the repository, and have every team member work against it.
Creating a Repository
It turns out that creating a central git repository is a process that takes only a few steps. First, you have to install git on a server that can be accessed by all the team members. Then to set up a central repository, follow the steps below:
- Create a project directory on the server that is accessible to all the developers. E.g. /Git/SampleProject.git/
- Navigate to the directory, then create a bare repository using the following command: git –bare init
That’s it. A central repository is now created on the server. Developers can start cloning from the repository using the right path (e.g. ssh://www.example.com/git/SampleProject.git).