My Octopress Blog

A blogging framework for hackers.

Git in Four Commands

Git is not a complicated tool for most things. I still find it a little tricky to set up for multiple users, but even that’s pretty easy. It really caters to the use-case where you’re just starting a project, or are the sole developer, but just want to keep track of changes and versions, make branches, etc.

The first major point of git is that everyone has their own copy of the repository. When you commit changes, you commit them to your local copy of the repository. If you are working on a group project, there is a shared resource that can be pushed to and pulled from, but I actually like that it takes an extra command to do that – it forces me to make sure that it’s what I actually want to do. Now, to the bare-bones commands:

  1. git init – Wherever you’re writing your code, type “git init”. It creates an empty repository in that directory (there’s a magical hidden folder “.git” that gets created and knows things).
  2. git status – Git knows which files have changed since you last saved changes, and it will happily tell you which files are new and changed with this command.
  3. git add – When you change files and are at a point where it make sense to save changes to your code (a bug fix, a new feature, etc.), then tell git which files you want to put in this commit with “git add”. If committing a set of changes with git is like shooting a gun, then adding files to be committed is like loading that gun. Git knows which files have changed, but it can make sense to group changed files into different logical commits. For example, if you fix two bugs between commits, you might want to add the changes for each bug fix separately.
  4. git commit – When you have added a bunch of changed files to be committed, now you’re ready to actually commit those changes. Type “git commit -m ‘A short, meaningful summary of the changes that happened.’”

There is a lot more to git, and a million tutorials, that will explain things in more detail, but these are the commands I spend 95% of my time using, and enough to at least get you starting tracking changes for anything and everything. It doesn’t matter very much what version control you use, just use something.