Git in Four Commands

On 06.05.11, In computer science, By dan.lecocq

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.

Tagged with: •
 
0 Comments
Leave A Response

Git(1) – Your Kind of Version Control

On 11.10.09, In computer science, life, By dan.lecocq

I’ve been around the block a time or two (or more) with subversion, but until recently I had limited experience with git. Sure, every now and then I’ve used it to check out projects, but not for my personal use.

No longer. And as of right now, I don’t have any intention of using anything but git for personal development.

Last week, I held lecture for parallel programming and I talked about using subversion for versioning, and I began to suspect that something was horribly wrong. Questions started springing up – where does the repository live? Am I calling svnadmin on my own machine? Where do I check out the repository? Though there are answers to these questions, for many things, such a model just doesn’t make sense.

If I’m working on a project that I’m not syncing between several computers, but I just want to have different stable versions and to try different crazy ideas using branches. It mitigates the cost of reverting drastic changes to code.

Use Case: You’re showing someone your code, and want to show off a neat feature you’ve made, or a problem you’re encountering, something about the project, invariably you’ve run into a problem where it doesn’t compile at the moment. You type furiously, trying to find and undo the most recent changes, but to no avail – there is no hope of getting it to compile in the 5 minutes you have someone’s attention. Enter version control. Revert to the last working copy and victory is yours.

In fact, just today I was asked if I could pull up some code I had been working on to show to a professor. Unfortunately at the moment it wasn’t compiling but was able to switch versions in 20 seconds and show off some very recent work from earlier in the day, thus saving face.

Use Case: You’ve got some crazy idea for an implementation you’d like to try out, but are worried about reverting back all the massive changes you’ll have to make in the code. Worry not! Create a new branch and feel free to change your code in every way you can think of and not lose other branches under development.

Use Case: You’ve got multiple versions of code each implementing the same basic algorithm but with different mechanisms, techniques, etc. and have to turn it in as part of a project. Just archive the whole directory (in a tarball or zip) and the user who unpacks it has access to every version your code has been in. Each branch, each stage of development. And very light-weight to boot.

I can’t speak for others, but I will be using git for the foreseeable future as it’s incredibly easy to use and alleviates many of the problems I encounter regularly with development.

Tagged with: • • • •
 
3 Comments
Leave A Response
Go To Top »