Why I Don’t Just Use Git for Development

Standard

Recently, at PayProMedia, we started a new project. It’s a massive undertaking and we have several developers working on it on and off site. So, we decided to use Git instead of just making edits and changes over FTP. The basic synopsis and summary of Git is that it’s a version control system. Very powerful, very robust (more on this in a little bit). But still, fairly easily to learn (especially the basics of making and tracking changes). It can get fairly complicated and can also used for the largest of projects by power and super users. The more I’ve learned about Git, the more I like it.

One day, it hit me:

I can track ANY kind of file.

My world just opened up. I saw the light! (In a very digital kind of way.) Then, all of a sudden, I realized that that spreadsheet I had been working on and accidentally saved over or deleted, didn’t have to be lost (well, after I set up Git, it wouldn’t have to happen again). Or, that photo that I was nervous about making edits to (if tracked with Git), could be edited and re-saved with confidence.

How is this possible and easy? Well, let’s look at a few things.

  1. Git is free and open source. It was originally developed by Linus Torvalds and the Linux team. So, no upfront cost, other than learning (which you have to learn some system to keep track of different versions of  a file)? Yes, please.
  2. Git is available on Windows, Mac, and of course, Linux. It’s even available for Solaris. So, no matter where you are, what computer you’re working on or can afford, who you’re working with, you can use Git. Hallelujah!
  3. Once you have Git set up (which doesn’t take long), tracking a file’s progress is very simple. You have to be comfortable with two things, if you’re the only person working on a document: add and commit. “Add” simply adds a file to what’s called a staging area. Once you’ve staged a change (i.e. finished a thought/section of a paper), you “commit” that change to the Git database. Once you tell the system to commit your changes, Git will ask you for a commit message. It’s helpful to be descriptive here. Just saying something like “Revised copy” won’t help you when you’re looking for a specific change you made to a file. Instead, something like, “Reworded introduction paragraph to be have more personality.” Trust me, this will be helpful. Git then takes a snapshot of the file, and stores it.
  4. Another advantage: you can restore any portion of a file (or the whole thing) at any point in time. So, let’s say the person you’re writing for says, “You know, let’s actually make that introduction more professional and less personable.” Well, now, you can go back to the the commit you made when you changed that and restore even just that portion of the file. Bam. Now you have less work to do. Or, maybe you’re like me and you accidentally delete things. Well, you can just restore the whole file. Thank you, Git!

There are a lot of other benefits to using Git, such as working with other people on the same file and easily merging the changes, having branches for different thoughts or sections of your paper/work, or being able to visualize the amount of work that you’ve put in to something (because now, you can see what the article or graphic design piece started out as!).

I could go on, and on, but I will leave the rest up to you. What will you do with it? Could Git help you in your workflow?

My primary development environment is OSX, where I use SourceTree as my Git GUI and Coda as my coding platform.

Here are some StackExchange discussions I found after deciding to look into this a bit further. Enjoy!

http://academia.stackexchange.com/questions/5277/why-use-version-control-systems-for-writing-a-paper

http://academia.stackexchange.com/questions/1261/simplest-way-to-jointly-write-a-manuscript/1263#1263