Introduction to using git locally
Wednesday 14th January 2009
Categories: Guides, Code, FLOSS
Why git?
Why bother using git? This is something of a loaded question. The first question this asks is: why use source control? There are various reasons, but the simplest is to keep hold of old versions, in case you need some piece of code that you've deleted, or if you've introduced a bug and need to revert a change.
Using a distributed version control system (DVCS), which git is, allows us to do certain things more easily that more traditional centralised version control systems, such as CVS or Subversion. In particular, a DVCS makes it painless to create branches with your own changes, and merge in other people's changes, picking and choosing what changes you want to include.
Finally, we have the question of: why git specifically? One reason might be popularity - there are plenty of users of git, so getting help shouldn't be too hard. (Of course, there are plenty of other popular DVCSs around.) Speed is another factor - what can take minutes on certain version control systems can take mere seconds using git. Providing some proof for this paragraph is way beyond the scope of this article, but there is a plethora of articles online on the topic.
This guide aims to show just some of the commands that git lets you use - there are certainly far more than are listed here. It also assumes that you're only going to working locally. Much of git's usefulness becomes apparent when you start working with other people, but even for one-man jobs using git can be tremendously helpful.
Of course, any corrections or suggestions are welcome! So, let's get going.
Getting started
For any git command, git-<command> and git <command> usually do the exact same thing. Especially helpful are the man pages for each command i.e. man git-<command>.
To start, we probably want to create a git repository. This is easy enough - in the directory you want to track, just run the command:
git init
This will create a repository containing a single branch, master. Anything in this directory is said to be the working tree.
To get things into the git repository, we first need to move them into the index. The index can be thought of as the staging area for the next commit. This can be done using:
git add <my-file> <some-other-file>
This will add <my-file> and <some-other-file> to the index. If you instead specify some directory in the list of things to add, it will add everything in that directory. Since a single dot represents the current directory, we can add everything in the working tree by typing (assuming you're in the working directory):
git add .
Once you're happy with the state of the index, you can commit your changes by typing
git commit
Change the commit message as you see fit, and your changes should enter the repository. Note that the first line of the message will be used a summary for that commit.
If you use the -a flag when committing i.e.
git commit -a
git will add everything that it tracks to the index and commit it. Say we've already committed a file foo. We then modify foo and add a new file bar. When we use the command git commit -a, git will commit the new version of foo, but not bar.
If you want to remove <my-file> from the index, use the command:
git rm --cached <my-file>
This will only remove the file from the index, so that it won't be part of the next commit. If you actually want to delete the file as well as remove it from the index, just drop the --cached flag:
git rm <my-file>