This year, my local ACM chapter is aiming to present a series of talks and lectures that are practical in everyday use as a developer. The first talk’s subject was the use of git and GitHub, and was presented by yours truly, with the idea being that presenting this first would allow all of our future presentations to have the code stored on GitHub for everyone to access. Now, I am far from an expert at working with git. I’ve never been a part of a huge and active repo, and I’ve never used it in a truly corporate environment. However, I have been annoyed enough at it to learn to use it in a practical manner. I prepared a small set of slides, although looking back at them they’re woefully incomplete. The actual presentation was…not the best. It is hard to present something to your peers. Despite the presentation being a bit lacking, I thought it would be a good idea to let fellow students know why they should use git and GitHub.
Most students don’t need git. At least at my university, we tend to focus mainly on small projects that are designed solely to teach us a single concept. Of course, most of us realize that this isn’t how real development works–and those who don’t are in for a shock. But still, most students don’t truly need their work to be in version control. So why use it?
One day, you’ll be forced to use version control by your employer. Even if they don’t use git, they’ll have something put in place that you’ll have to learn. Getting used to committing your code, backing it up on a remote server, and possibly receiving critique of your code is a good idea because it’ll save you a headache in the future.
Students go to school to get a job. Employers want employees who don’t suck. If you’re reading this, you’re probably trying to get a job that involves some sort of programming. It stands to reason that potential employers want you to not suck at programming, which is why you’ll often have to do a technical portion of your interview. Wouldn’t it be great if employers could just look at your resume and know that you’re a decent programmer?
That’s part of what GitHub does. Put a link to your profile on your resume and BOOM potential employers can go look at your code. Of course, they likely won’t base their decision solely on your GitHub repositories, but them seeing the repos could be the difference in even getting the initial interview.
Something else to keep in mind is that having code on GitHub shows that you’re competent enough with a big and current technology, that you have a self-starting attitude to have put it there in the first place, and that you’re actually taking the time to do something outside of classes. It shows that you care about what you’re doing, which is important to people looking to hire a developer.
Let’s face it, working in groups can suck. Often, you get people who don’t show up to meetings, fail to contribute anything useful, or are just plain obnoxious. We all know those people and have been in a group with them. Adding in the complexity of managing a potentially large codebase makes it even worse.
There are a few solutions to group coding, but most of them aren’t good solutions. Git was literally designed for a group to manage code together. You have the ability to keep everyone on the same page, which is invaluable. You have records of exactly who did what. You have a record of every single line of code, just in case something breaks or you need to remember something. Heck, you’ve even got the ability to keep track of bugs and other miscellaneous information that you’d normally just ignore.
Saves Your Neck
It’s the due date of a month long project. You’ve pounded out more lines of code than you care to even think about. Last night you tested it and it worked perfectly. This morning you woke up and, just to get that wonderful feeling of having conquered a problem, run the project again. Suddenly, and for no good reason, it doesn’t work. You can remember making a few small changes after it worked…but nothing that should break it. Okay, maybe that example is a little contrived, but just a little. Everyone has experienced that sinking feeling of code miraculously breaking. Git can, usually, save you from that. If you were keeping your code in git and committing only at goals, such as completing the project and having a running product, you could just roll back to the last working commit. Done. Now that doesn’t always fix it, but it is way better than just poking around trying to figure out what the heck happened to your code.
Also good to note is that your computer can suddenly explode all over the place, and your code is gone. That can be solved with Dropbox, sure, but it’s just as quick and easy to push it to GitHub and you get all of the benefits of source control.
So let’s tally that up. It makes your future job a little easier, it makes actually getting a job easier, it makes working in groups easier, and it has the ability to save you from potential disaster. That sounds good to me.
Now, these obviously aren’t all of the benefits of using git and GitHub. As a student though, these are the big ones that I’ve found useful to me, discussed in a manner that makes sense to me. If you still don’t think you’d find git useful, use it for a few of your next projects. The bigger the project the better. You’ll thank me later.