Saturday, January 4, 2014

Git

I use a Git  often to help share my code with other people and to back up my work on a remote server somewhere. At my previous job we used a paid service from GitHub to help manage our code. Previously we had been using Dropbox to store our code which is a really horrible way to share code. Dropbox automatically syncs a folder across all  devices (primarily computers). While programming with several people this can be a problem because I might be working on a section of code A, and my colleague might be working on section of code B. I modify the code in a way that effects the functionality of sections A and B, and then the person working on section B doesn't realize that changes have been made and can't figure out why things aren't working. In other works, auto-sync while sharing code is a bad idea. .

In contrast, Git allows developers to control the synchronization of code with other developers by using a variety of tools and techniques. When you have finished something note-worthy, then you make a "commit" of your code. This is a saved snap shot of everything in your git repository (folders where you setup git). You can share this snap shot by uploading it to a server, and then sharing it with others. GitHub and Bitbucket are the two companies that I use their services for my git server. If your colleague downloads the code, makes some modifications and then uploads it to the server again, then you also can see that changes have been made, and git will force you to merge the two commits (snapshots of all the files). You can change the merging strategy that git will use. If git cannot auto-merge the two snap shots, then it will let you know and ask for your help.

Git is different than Dropbox as well because git saves the differences between commits of your code. So instead of uploading a file to a git server, git will only send a diff file that describes what is different about your code when compared to a previous commit. The diff files are saved so that if you need to go back to a previous version of the code because something is not working, then it is trivial to tell git to undo the differences. This ability to go back has saved me so many times from wasting hours and hours of work!

Git also allows you to have several versions of the code by making different branches. So if you are working on feature X and your friend is working on feature Y, but you don't want to bother with merging the two until you both finish your features, then you can just make 2 branches of your code. Branches can be merged together in a control manner later on.

Git is simple, but at the same time it is very complex to full use its power to the max. I'm sure I don't use all of its potential, and every time I need to do something that is out of the ordinary set of commands, then I always Google to find the correct syntax.

Dropbox, Google Drive, SkyDrive, and Ubuntu One are superior to git when you have a file that is in a non-human readable format. For example, a .exe or .bin file shouldn't be uploaded to git because the diff file is meaningless.

Github offers several articles on how to setup git easily. I personally use Bitbucket as my primary git service provider because I can have free git accounts without making them public (in contrast to github). The only constraint on Bitbucket is that you are limited to 5 team members for a free account.

Git is a valuable too for any engineer working on software development. I've found that most of my mechanical engineer colleagues are ignorant of tools like Git to help them keep track of their code. Instead they are not backing up their code daily, emailing huge sets of files to share code, storing code long term on CDs, and other bad code management practices.  So if you are one of those engineers who knows more about how to stack blocks to prevent overflow than what a stack overflow means, then I'm guessing you might be one of those people who needs to learn how to use git for your next coding project.