Whether or not a random person decides to view source is irrelevant. More relevant, however, is whether a developer will come along in six months to make a change and wonder who did the ugly hack and why - they will of course be able to check the source control commit history for that line and see the explanation for making that particular change, right?

Jeepers! Next you'll be saying you were working directly on the live server for those three hours.

git init .

Then create/edit the .gitignore file and add the names of any files you don't want included in the repo (passwords, compiled stuff etc.), then

git add .
git commit -am "Yay, my first commit!"

That sets everything up. Then when you make changes:

git add lib/some_new_library.rb
git commit -am "Add SomeNewLib to repo. Fix a broken thing."

The '-am' parameters mean, respectively: automatically add modified files to this commit; use the last part of the command (the bit in "quotes") as the commit message.

You can make a new branch based on the current one:

git checkout -b fancy_feature

The -b means 'create a new branch'. Leave it out to switch to an existing branch. You can merge changes from another branch to the current one:

git checkout master
git merge fancy_feature

This switches to the branch 'master', then merges 'fancy_feature' into it. If you edit the same part of a file in two different branches, then try to merge them, you'll get merge conflicts, which are a pain in the arse to fix, so don't do that.

To see which branch you're on, and what files have changed since last commit:

git status

To see what specific changes you've made since last commit:

git diff

You can include a filename after that to only diff that specific file.

Thus concludes my 5-minute intro to Git.