Intro to git - Part 1

git logo

I’ve been using git for quite a few years now for version control on my software projects. It’s pretty popular and easy to use but I continue to meet programmers who have tried it but just can’t seem to grasp it. While it’s sad to see a colleague struggling with something, it’s worst when you have them ‘learning’ on a live project - no one has fun there. I’ve been lucky enough to have presented sessions on git in the past at Orlando .Net Code Camp, and figured that having a series of posts breaking down those sessions could have some value.

In this first post, I’m going to talk a little about the ‘rumors’ about git and why you’d want to use it. Then in the latter posts we’ll get the overview of the process and then zoom in on each step to get a better understanding. It’s kind of a dry subject, but I’ll try to make it as informative and entertaining as I can.

Let start with the common misnomers about git that I’ve heard.

It’s too hard to use.

Well everything is hard the first time that you do it, think about the first time you rode a bike - didn’t end well I’m sure, but after some time you stopped even thinking about it. As much as I wish that there was a magical way to achieve perfect version control, there isn’t.

It’s only for the command line.

Nope - while there is a command line, there are a lot of different graphical user interface’s for them. Additionally, it works on many platforms. I’ve used it on Windows, Linux, Android, and even my ThinkPad Chromebook - I know Chrome OS is based on Linux, but I’m making the point here.

My project is too big and complicated for that.

Yeah, this is my absolute favorite reason not to use git or any version control system. I agree sometimes projects are large and complicated, but think about this - git was created to manage the Linux kernel. None of my projects are that complicated, are yours? Oh, and as a side note Microsoft also uses git to manage Windows development - just saying.

It takes too long to use.

Hmm - after using git for years I’ve gotten to the point where it takes about 30 seconds to commit via the command line. With graphical user interfaces, it’s even faster. I’m not sure that this one is a valid argument.

Why use git?

Well there are a bunch of reasons to use git, first off it’s fast and once you learn it - it’s simple to use. git also copies the entire history to your local machine, which allows you not only to look back at prior versions, but to work on features independently from the other’s on your team. Additionally, there is a concept of branches, which basically let you work on tasks independent of each other. Branches make it easy to go from a feature to a bug fix without taking all day to ’re-setup’ your system. The other neat thing that it does is it allows you to quickly roll up and down in your versions - this is awesome for when you want to find out when you added a bug to the software. Finally, while not the main reason to learn git it’s a big one - the skill is in high demand, so why wouldn’t you want that on your resume?

Hopefully I’ve sold you on wanting to learn git. I plan on making this a series, so you can always come back to this page and check out the related posts, they’ll be at the bottom of the page.

Links to the other posts in the Learning git series

  1. Intro to git - Part 1
  2. The git cycle
  3. Setting up git
  4. Initializing git
  5. What's a remote in git
  6. git branches simply explained
  7. git Merges Demystified
  8. How to use git flow
  9. git stash and pop