GIT - a tool for rapid development and integration

Few years back I had the first taste of GIT. At that time GIT was more to geeks that anyone else, it was basic and tools were not that policed, documentation was limited to man pages, etc. But things have changed it has come long way. Based on the experience I also wrote a blogpost mentioning GIT is not enterprise ready.

Well have I changed my mind? Not exactly! Some of the concerns still exists, but definitely with more experience in different working environments help me realize that there are few other concerns that some enterprises may come up like extensive branching and merging which outweigh the minor problems of one centralized repo concept.

In all most of all of the companies that I know does keep a central repository of the their code base. And I'm yet to meet anybody who says that his/her company is looking for distributed repository. But there is a quite burning questions that I hear from lot of my colleagues, that is how you keep different versions of active development, merge  and release them, do bug fixes and patch them. So I was very interested what would be the best tool for this in terms of version control.

I was using SVN first at my office, then I joined a company which uses CVS. It was like going back in time for me. So many things I did easily seems to be very difficult. Keeping track of changes and location them was nightmare. Out of all of it, worst nightmare was merging. It was so difficult and we had to invent our own procedures to make sure nothing is missed and no neck breaking conflicts. Even though we came masters of it, process was very tedious and not easy to follow. Also there could be so many human errors. Thus it became evident that we handover over burden to a repo which could handle it and simplify and improve our process. So after few studies and trials we moved to GIT.

GIT is no doubt is a wonderful tool, but we had to look into few things before migration. Some of them I have listed below

1. Migration support - CVS to GIT in our case but there are other migrations also 
2. Support for main operations like branching, merging, conflict resolution, tagging, history, etc
3. IDE support 
4. Access control and security
5. Integration support for bug tracking and other systems 
6. Help and resources

After the migration no major problems were detected. Only thing that we should keep in mind is that even though your existing repo (CVS) might have merged branches to head, those changes might not reflect in GIT. Thus existing branches be good if you want to keep history only. Also leaving merging after the migration is a very bad idea if you have already done partial merge of that branch. Anyway anything after migration is working great for us.

Out of all the things about GIT most valued feature for us is the branching and merging. Clearly it is designed by people who really knew what is branching and what is merging and whom should do it. Also in addition that low bandwidth usage and performance is great.

Also once you switch to GIT some of things that you might have done in other version control system like CVS no longer needed. But usually it take some time to get whole team to make the switch. But sooner the better, otherwise even tool is good, your process might be screwing up things.

May be in coming days I will write about what are the lessons learnt from migration and things to do and not to do!