Version control with Git

I've recently started using Git for version control of all my personal projects. It works so smoothly that I don't have any reservations about using version control. That means I commit small changes very often; as a result, I'm never afraid of leaving my projects in a wedged state, even if I'm making big changes.

This post only discusses Git basic usage. I'll write about its distributed features in future posts.

To start managing a directory with Git:

1. Do the following to initialize the directory:

   git init

2. If you have existing files you want to start managing, do

   git add .

   to add all the files in the directory, or

   git add FILE ...

   to add only particular files.

3. Then do

   git commit

   Git prompts you for a log message and records your first commit. It will print a message of the following form:

   Created commit 1e169f6: Add new file.
    1 files changed, 15 insertions(+), 0 deletions(-)

   Congratulations!

Like SVN, Git store per-tree versions rather than per-file versions. However, instead of assigning version numbers like SVN does, Git assigns a unique hexadecimal identifier for each commit. Although these identifiers are long (40 characters), when you wish to refer to a particular commit, you only need to type as many characters are needed to make a unique prefix.

My typical workflow looks like this:

1. Do some editing:

   emacs FILE ...

2. Add files to Git's staging area:

   git add FILE ...

   Do this whether the files are new files you've added, or existing files you've modified.

3. Commit the files in the staging area:

   git commit

   Again, Git prompts you for a log message and records a commit.

As a shortcut, git commit -a is equivalent to running git add with any modified files before running git commit. (It does not, however, pick up newly created files.)

The following commands are used to explore the project's history and current state:

• git log shows recent commits.
• git status shows which files are in the staging area, which files have been modified, and which newly created files are not managed by git.
• git diff shows changes in your working copy.
• git diff --cached shows changes in the staging area, that is, what will be committed when you do git commit.
• git diff cd12..ab34 diffs the revisions cd12 and ab34.
• git reset --hard restores your working copy state to that of the last commit.

The CVS version of GNU Emacs supports Git in VC, so it knows when your file is being managed by Git. When it is, you can use the following VC commands:

• C-x v v commits the current file.
• C-x v = shows a diff between your working copy and the last committed version (or between any two committed versions).
• C-x v g displays an annotated version of the file showing, for each line, when that line was last modified, and a heat-map displaying older and newer code in different colors.

To install git on Ubuntu: type sudo apt-get install git-core.

Further reading: Everyday GIT with 20 commands or so, A tour of git.