Git is a distributed version control system developed by Linus Torvalds. It is used for managing Linux kernel development as well as for many other projects.
There is a variety of good information about Git available online, including:
- The official Git documentation, which includes both a tutorial and a complete reference manual with links to individual subcommand documentation.
- Pro Git is an excellent free online book.
Most commands have built-in documentation you can access with the --help option:
You can generally access the same documentation as Unix man pages, e.g:
Creating a repository
git init to create a git repository in your current directory:
git init creates a git repository in your current working directory. You will add files to this repository using git add. This gives you a repository (the
.git directory) and a working copy (everything else).
Tracking an Existing Project
If you are going to start tracking an existing project with git, you will generally start like this:
This initializes the repository. Next, add the existing files to the repository:
git add command schedules files to be committed to the repository.
Unlike Subversion, if you modify a file you (generally) need to git add that file in order to make the changes part of the next commit.
git reset command to "undo" an add operation:
This resets the index but leaves your working directory untouched. You can also use
git reset to revert to a previous commit; read the documentation for more information.
git commit to commit files to your local repository:
git commit by itself will commit any changes scheduled using
git add. If you would like to commit all locally modified files, use the
You may also commit a subset of modified files by specifying paths on the
git mv to rename files in the repository:
git tracks files by cryptographic checksum, rather than by name, the
git mv command is not strictly necessary. If you manually rename a file and then do a
git rm file followed by a
git add file, git will correctly recognize that you have simply renamed it (because the checksum is still the same).
git rm to remove files from the repository:
What's changed: status
Use git status to see a list of modified files:
The output of
git status will look something like this:
The files listed as "changed but not updated" are files that you have modified but not yet added to the repository. "Untracked files" are files that have not previously been added to the repository.
What's changed: diffs
Use git diff to see pending changes in your working copy:
The output of git diff is standard diff output, e.g.:
You can also use git diff to see the changes between arbitrary revisions of your project:
- Changes in working copy vs. previous commit:
-Changes between two previous commits:
Working With Remote Repositories
Cloning a Remote Repository
git clone command to check out a working copy of a remote repository:
git clone will clone the remote repository to a new directory in your current directory named after the repository, unless you explicitly provide a name with the DIRECTORY argument.
This is analogous to Subversion's checkout operation.
You can only clone the top-level repository; unlike Subversion, git does not allow you to clone individual subtrees.
Updating your working copy
git pull to update your local repository from the remote repository and merge changes into your working copy:
git pull by itself will pull changes from the remote repository defined by the branch.master.remote config option (which will typically be the repository from which you originally cloned your working copy). If there are multiple remote repositories associated with your working copy, you can specify a repository (and branch) on the command line, e.g, to pull changes from the branch master at a remote named origin:
git push to send your committed changes to a remote repository:
git push by itself will push your changes to the remote repository defined by the
branch.master.remote config option (which will typically be the repository from which you originally cloned your working copy). If there are multiple remote repositories associated with your working copy, you can specify a repository (and branch) on the command line, e.g, to push your changes to branch master at a remote named origin:
If you attempt to push to a repository that is newer than your working copy you will see an error similar to the following:
To fix this, you need to pull from that repo, merge changes, and then push.
Sharing your repository
If you will be sharing a repository with others (or with yourself on multiple computers), you will need to create a "bare" repository – that is, a repository without a working copy. You do this with the
-b flag to
You can then clone this repository, pull from it, and push to it as described in the previous section.
A conflict occurrs when two people make overlapping changes.
They are detected when you attempt to update your working copy via git pull.
You may discard your changes, discard the repository changes, or attempt to correct things manually. If you attempt to pull in changes that conflict with your working tree, you will see an error similar to the following:
To resolve the conflict manually:
- Edit the conflicting files as necessary.
To discard your changes (and accept the remote repository version):
git checkout --theirs README
To override the repository with your changes:
git checkout --ours README
When you complete the above tasks:
- add the files with
- commit the changes with
Log, Tags, and Branches
The git log command shows you the history of your repository:
git log with no arguments shows you the commit messages for each revision in your repository:
Tagging and branching
Git has explicit support for tagging and branching.
git tagmanipulates tags
git checkoutmanipulate branches
Create a tag:
Creates a lightweight tag (an alias for a commit object). Add
-a to create an annotated tag (i.e., with an associated message). It is also possible to create cryptographically signed tags.
To list available tags:
Create a new branch:
To switch to a branch:
For example, you want to enhance your code with some awesome experimental code. You create a new seas-workshop-dev branch and switch to it:
You make some changes, and when things are working you commit your branch:
And then merge it into the master branch:
The Git Index
Git is not really just like Subversion (or most other version control solutions). That's mainly because of the git "index".
- The index is a staging area between your working copy and your local repository.
git addadds files to the index
git commitcommits files from the index to the repository.
The diff commands uses the index:
git diffis the difference between your working copy and the index.
git diff HEADis the difference between your working copy and the local repository.
git diff --cachedis the difference between the index and the local repository.
Refer back to this illustration if you get confused:
(This image used with permission.)
Git Plays Well With Others
Git can integrate with other version control systems.
- It can act as a Subversion client (may be the only Subversion client you ever need).
- Can import a CVS repository.
Integrating w/ Subversion
You can use git as your Subversion client. This gives you many of the benefits of a DVCS while still interacting with a Subversion repository.
Cloning a remote repository:
-s flag informs git that your Subversion repository uses the recommended repository layout (i.e., that the top level of your repository contains trunk/, tags/, and branches/ directories). The HEAD of your working copy will track the trunk.
This instructs git to clone the entire repository, including the complete revision history. This may take a while for repositories with a long history. You can use the -r option to request a partial history. From the man page:
Committing your changes back to the Subversion repository:
Before you push your changes to the Subversion repository you need to first commit any pending modifications to your local repository. Otherwise, git will complain:
To fix this, commit your changes:
And then send your changes to the Subversion repository:
Updating your working copy from the Subversion repository:
As with git svn dcommit, you must have a clean working copy before running the rebase command.
Integrating w/ CVS
You can import a CVS repository into git (this is a one-time, one-way operation). The CVS import feature requires
cvsps, a tool for collating CVS changes into changesets.
This may take a while: