Why you need git

This is going to be a rather short post that I will be sure to follow up with on a later date. I recently started a crash course with git to understand the true benefits of it and wanted to share with other developers out there who have not yet given it a try or are overwhelmed by what they find.

I’m approaching this article sincerely from a novice viewport. This is not a tutorial, it is simply an explanation of how git can help you.

And let’s face it, git is nothing new. The main point of this article is to show that git can be useful for almost anyone. I myself stayed away for so long thinking it was only needed for intense programmers, people collaborating with others and really large projects. Read on and you’ll see why this isn’t true.

What git is

Git is version control. As far as I can tell, it is universally accepted as the best version control. In layman’s terms, it allows you to make checkpoints of your work so that you can see a log of changes that have been made file in a project and revert to older checkpoints if needed. The checkpoint includes information like when, by who and then the exact changes (deltions and additoins) that were made in a file, among a few other things including a message you contribute with each checkpoint.

Who can use git

Everyone. I mean it. This is what threw me off at first. I’m a web developer, which now seems like an obvious candidate for git, but my original thinking was that git was used by programmers who want to collaborate on large projects. This is not the case!

If you work alone, or with a team on a private project or with other people on the web doing open source projects, git is for you. If you are a writer working on a novel, git is for you. Programmers can definitely benefit using git, but so can designers (actually, here’s a great article on using git as a designer). Mac, Linux and PC users can all use git. People with no internet connections or intermittent internet connections can use git.

The best uses for git are when you’re working with plain text files like .css, .js, .html, .php. .rb, .txt and so on. This is because git let’s you see the changes that happen to a file.

Git also lets you branch your project and sort of veer off course. This is great in collaboration, but again, even useful if you’re working alone. Say you want to implement a new feature but aren’t sure how, you can branch off your main code and try something. You give up but don’t want to delete you changes, so you go back to where you branched and try something else. At this point you come to realize that the first idea was actually better if just made some simple changes, so you revert to the original branch and work from there. Meanwhile you’ve kept a log of the entire process and always had means to undo your mistakes and try again.

Perhaps the best feature of git is that it doesn’t need to talk to the web. This is what made git click for me. I had a predisposed image of git being this giant beast that lived on the internet and needed to constantly be fed commits. This is probably because most version control out there is that way. But git is something you can set up on your computer and use by yourself to track your project without ever needing to push to a server.

The limitations

Git has a few limitations that I’ve seen so far. The first one is that when you are not working with plain text files, you are not going to be able to see every change, line for line, like you would with plaintext files. For instance, if I edit my a CSS file and commit the changes in git, I’ll be able to look back at that change any time and see the exact lines I’ve either removed or added. On the other hand, if I’m a designer and I change a .png file, I’m not going to get a visual of the changes; Instead, I’ll only see what appears to be gibberish in the file’s encoding.

Git is also a bit intimidating. Using git on your team requires that everybody puts in the time to learn it, which can be a daunting task. It took me a while to finally give it a shot. There are great GUI tools out there but to really get into it, I highly recommend learning the git’s CLI.


Again, this is just a quick article about the very basics of git; what it is and who it helps. This is the article I wish I had read 2 years ago, instead all I knew was from having to download something off github every now and then. It can be confusing and intimidating, which is why my hope is that the fledgling developers reading this are having an now thinking about giving git a chance.

To get started, download git.

Then read the first two chapters of the provided documentation, minimum. The first two chapters will give you the basics on how to use it with your project. Good luck!