...

Git is a distributed version control system developed by Linus Torvalds as a replacement for BitKeeper, . It is used for managing the Linux kernel source tree. For the following commands, please see the documentation at

• http://www.kernel.org/pub/software/scm/git/docs/v1.6.6.2/

and the links from there for each sub-commanddevelopment 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.

Getting Started

Getting help

Most commands have built-in documentation you can access with the --help option:

$ git init --help

Also available via man, You can generally access the same documentation as Unix man pages, e.g:

man git-init

Creating a repository

Use git init to create a git repository in your current directory:

$ mkdir myproject
$ cd myproject
$ git init

Here the documentation for this command.

git init creates a git repository (named .git) 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:

$ cd myproject
$ git init

Initialized empty Git repository in .../.git/

...

This initializes the repository. Next, add the existing files to the repository:

$ git add .
$ git commit -m 'initial import'

If you are creating a repository that people will be accessing remotely, you will normally want to create a "bare" repository, which consists of just the contents of the .git directory and no working copy. You do this with the -b flag:

$ git init -b

Adding files

The command git add schedules files to be committed to the repository.

git add PATH [PATH ...]

Adding files

The git add command schedules files to be committed to the repository.

$ git add file1.c file2.c

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.

Use the git reset command to "undo" an add operation:

$ git reset HEAD

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.

Committing changes

Use git commit to commit files to your local repository:

$ git commit [-a] [PATH ...]

The command git commit by itself will commit any changes scheduled using git add. If you would like to commit all locally modified files, use the -a option:

$ git commit -a

You may also commit a subset of modified files by specifying paths on the
command line:

$ git commit path/to/modified/file

...

Use git mv to rename files in the repository:

$ git mv SRColdname DSTnewname

Because 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).

...

Use git rm to remove files from the repository:

$ git rm PATH [...]file1.c

What's changed: status

Use git status to see a list of modified files:

$ git status

The output of git status will look something like this:

...

Use git diff to see pending changes in your working copy:

$ git diff

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:

  Code Block
  git diff <commit>

-Changes between two previous commits:

git diff <commit1> <commit2>

Working With Remote

...

Repositories

Cloning a Remote Repository

Use the git clone command to check out a working copy of a remote repository:

$ git clone REPOSITORY [DIRECTORY]

...

Use git pull to update your local repository from the remote repository and merge changes into your working copy:

$ git pull [REPOSITORY [REFSPEC]]

...

Use git push to send your committed changes to a remote repository:

$ git push [REPOSITORY [REFSPEC]]

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:

$ git push origin master

Git doesn't like you pushing into a remote repository that is associated with a working tree (because this could cause unexpected changes for the person who checked out that working tree). You will generally want to create "bare" repositories for remote access (using git init --bare).

If you attempt to If you attempt to push to a repository that is newer than your working copy you will see an error similar to the following:

$ git push
To dottiness.seas.harvard.edu:repos/myproject
 ! [rejected]        master -> master (non-fast forward)
error: failed to push some refs to 'dottiness.seas.harvard.edu:repos/myproject'
To fix this, run git pull and deal with any conflicts.

...

, run git pull and deal with any conflicts.

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 git init:

$ git init -b

You can then clone this repository, pull from it, and push to it as described in the previous section.

Conflicts

A conflict occurrs when two people make overlapping changes.

...

To resolve the conflict manually:

...

• Edit the conflicting files as necessary.

To discard your changes (and accept the remote repository version):

...

• run git checkout --theirs README

To override the repository with your changes:

...

• run git checkout --ours README

When you complete the above tasks:

...

• add the files with git add

...

• commit the changes with git commit.

Log, Tags, and Branches

Viewing history

The git log command shows you the history of your repository:

$ git log [PATH]

git log with no arguments shows you the commit messages for each revision in your repository:

...

Git has explicit support for tagging and branching.

• git tag manipulates tags
• git branch and git checkout manipulate branches

Tags

Create a tag:

$ git tag [-a] TAGNAME

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:

git tag

To get information about a specific tag:

$ git tag -v
TAGNAME

Branches

List branches:

git branch

Create a branch rooted at START:

git branch BRANCHNAME [START]

If you omit START, the branch is rooted at your current HEAD.

...

$ git branch

Create a new branch:

$ git checkout -b BRANCHNAME

To create switch to a branch rooted at START and switch to it:

$ git checkout -b BRANCHNAME [START]

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:

...

$ git checkout master
$ git merge seas-workshop-dev
Updating 1288ed3..33e4a4c
Fast-forward
 version-control.rst |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
git: the index

The Git Index

Git is not really just like Subversion (or most other version control solutions)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 add adds files to the index
• git commit commits files from the index to the repository.

git: The diff commands uses the index:

• git diff is the difference between your working copy and the index.
• git diff HEAD is the difference between your working copy and the local repository.
• git diff --cached is the difference between the index and the local repository.

git: the indexRefer back to this illustration if you get confused:

Image Added
(This image used with permission.) git: Plays well with others

Git Plays Well With Others

Git can integrate with other version control systems. Can

• 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.

git: Integrating w/ Subversion

Cloning a remote repository:

git svn clone [ -s ] REPO_URL

The -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:

-r <ARG>, --revision

...

This allows revision ranges for partial/cauterized history to be
supported. $NUMBER, $NUMBER1:$NUMBER2 (numeric ranges),
$NUMBER:HEAD, and BASE:$NUMBER are all supported.

This can allow you to make partial mirrors when running fetch; but
is generally not recommended because history will be skipped and
lost.
git: Integrating w/ Subversion

 <ARG>
    Used with the fetch command.

    This allows revision ranges for partial/cauterized history to be
    supported. $NUMBER, $NUMBER1:$NUMBER2 (numeric ranges),
    $NUMBER:HEAD, and BASE:$NUMBER are all supported.

    This can allow you to make partial mirrors when running fetch; but
    is generally not recommended because history will be skipped and
    lost.

Committing your changes back to the Subversion repository:

git svn dcommit

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:

$ git svn dcommit

...

Cannot dcommit with a dirty index.  Commit your changes first, or stash them with `git stash'.

...

  at /usr/libexec/git-core/git-svn line 491

To fix this, commit your changes:

$ git commit -m 'a meaningful commit message' -a

And then send your changes to the Subversion repository:

$ git svn dcommit

...

Committing to https://source.seas.harvard.edu/svn/version-control-workshop/trunk ...

...

  M        seealso.rst

...

Committed r38

...

  M        seealso.rst

...

r38 = 03254f2c0b3d5e068a87566caef84454558b85b0 (refs/remotes/trunk)

...

No changes between current HEAD and refs/remotes/trunk

...

Resetting to the latest refs/remotes/trunk

...

Unstaged changes after reset:

...

M  git.rst

...

  M        git.rst

...

Committed r39

...

  M        git.rst

...

r39 = d1f884a3f945f6083541e28ab7a09ca8efc6343b (refs/remotes/trunk)

...

No changes between current HEAD and refs/remotes/trunk

...

Resetting to the latest refs/remotes/trunk

...

Updating your working copy from the Subversion repository:

git svn rebase

As with git svn dcommit, you must have a clean working copy before running the rebase command. git:

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.git: Integrating w/ CVS

This may take a while:

$ export CVSHOME=:pserver:anonymous@example.com

...

$ cvs login

...

$ git cvsimport -o cvs_head -C my-project

...