I joined Github back in September of 2010. At the time, I was working at SCPC. I can’t remember why I actually signed up but it was probably to be able to say that I in fact have a Github account.

For those of you who don’t know, Git is defined as a: “distributed version control system designed to handle everything from small to very large projects with speed and efficiency.”

In laymen’s terms think about Git this way: It’s an online system where you can store files and it keeps track of all of the copies of your work. Your coworkers can make a copy of what you’re working on, make changes and send it back to you. If you decide that the changes are good, you can merge them together and you have a better working copy. Git also keeps track of every single change that goes through its systems. You can go back and undo your changes without losing any of your files.

It took me almost four years until I finally set down to begin using git and making it a part of my workflow. Git itself is a command line tool, there is no GUI (graphic user interface). There are web based versions of Git, two of the most popular being: Github and Bitbucket.

Learning how to use the command line tool was a bit of a challenge, but once you’ve been using it for about a month, it becomes more muscle memory. For a great introductory tutorial using the command line system, read Lauren Orsini’s article.

The screenshot above is what it looks like when you’re working with git. Let me break down the steps:

1. cd desktop. This tells the computer to change the directory to the desktop.

2. mkdir new. This tells the the computer to make a new directory and call it new.

3. git init. This tells the computer to set up a new initialization of a git repository or repo.

4. git clone git@github.com:chipoglesby/RGA.git. This tells the computer to clone my RGA folder into this folder.

Of course, there are a few more steps to take before and after that, but those four steps will get you up and running. If you work alone like I do, Github can be a bit of an overkill, but it’s also a good piece of insurance in case anything happens to local copies of your work.

For a team environment, having a version control system is a must, there’s no way around it. if you’re interested Scott Chacon, a developer at Github, has an excellent post about their workflow at Github.

So why did it take me so long to get it?

Learning something new like git can be intimidating. I’m not a classic developer, I can only hack/use other people’s code right now. I’ve also always used the computer GUI and textedit so I’m very set it my ways.

Using Google Drive for the past eight years gave me the confidence that you can store things like word documents online and have every change saved with the ability to roll back at any point.

It’s also hard for me to wrap my head around why I would want to use it as an individual. There are plenty of great projects on Github and if i wanted to use it, I would just download a zip file and try it out.

So what changed?

I made my first init and my first push four days ago. I’ve been taking classes on Coursera. Part of the class involved knowing Python which is something I’ve always wanted to learn. I tested the waters in 2010, but quickly gave up. So I started the Google Python Exercises tutorial and have now started taking a easy class for Python on Code Academy.  The Code Academy class has made learning Python much easier than other methods.

Summary

If you work with computers and you have’t used git or github before and you work in a team environment, I highly recommend you check it out. There’s still so much more that I have to learn about the Git system before I could ever call myself “proficient” at it, but at least it’s a step in the right direction.