Git – Version Control¶
Until very recently I had never used any sort of version control system. I was aware of the existence of Git, SVN, CVS, Darcs, Mercurial etc. but never needed to use any. A version control system is a setup where by the changes to a set of files are tracked over time. This enables a timeline of the projects history to see what changes were made when and by whom. It allows for multiple people to work on a project and submit changes and patches.
A little bit of reading around and I decided to give Git a go. It has since changed the way I manage my code and configuration files. I tend to work on my desktop and laptop and I would copy the files I was working on from one machine to another. The files I would be working on would be the only current version. If I tried to implement a change and things didn’t work out then I would have to make corrections to have a working version again. Git solves this problem for me. Having a history of the changes made to the file mean that if a change is made that doesn’t work, the old version can be easily recovered. It is also possible to experiment and roll back the changes until things are ready.
I have found being able to branch and merge project files really useful especially in development of my firewall scripts. Each of my Linux machines has a customised firewall depending on which services are present and its intended function. Most of the script however is the same. Making a change to the firewall used to mean replicating the change to each script in turn and keep track of what changes had been made to which script. Using Git and various branches I can maintain a core set of rules common to all the scripts and individual scripts at the same time and merge at various stages to easily update all the scripts.
The same goes for configuration files. Modifying the systems default configuration to your specification is good until the default file itself is updated. Tracking the changes to certain files from the default I can see the modifications I made. I can then later import a new default file and merge that into my custom file. If as is usually the case the config file is the same on multiple machines I can replace with an upto date custom file.
One thing I have strayed away from is the moving of files between machines. Git is distributed version control. There is no central server required although a central location can be defined if required. The project exists inside a directory on individual machines. What this means is that I can have a copy of the project on my desktop and my laptop and work on them independently. I might an experimental branch on the laptop where I am working on a new feature and on the desktop I might have made a few bug fixes to the main branch. What I can do is fetch changes from one location, merge them and push them back. It also means I have multiple copies of the files. If I wanted to let somebody else contribute to the project they could fetch a copy of my files (assuming publicly accessible) work on them and send them back.
I doubt I have done the subject of Git and version control in general justice. But for me its has made a huge change to the way I work and all for the better. Git might not be for everybody but it fits my needs. Version control in general though is just too useful to ignore.