About This Page

This page is designed to give a quick overview of the most commonly used git commands, as used by the author. It is not designed to go into depth about them, and it is not going to list even a small fraction of all the options. The manpages are there for a reason, and they are quite good for the most part.

Concepts and Keywords

Repositories are what stores the state and history of your tracked files. They live in a .git directory (or in repo.git, if it's a bare repository). In may ways, git is a peer to peer versioning system, where history can be pulled between any two peers, and repository state is decentralized

Tracked Files are files that a git repository knows about and will keep track of. Files can be either tracked, in which case they are part of the repository, or untracked, in which case git ignores them.

Bare Repositories are git repositories that are not surrounded by a checked-out working copy. They tend to be used to act as a "central clone point", instead of being modified directly by developers

Commits are sets of changes to the code. in Git, they're tagged with a SHA-1 sum of the Git repository state, and referred to by this tag. Making a commit can be thought of as saving a file.

Tags are just a way of giving a certain commit a human friendly name, so that they can be referred to more easily in the future.

History is what any versioning system is about. History is a list of all commits done throughout the lifetime of the repository.

Branches are the basic unit of organization in Git. There is a default "main" branch called master, and you can, as desired, create topic branches to work on without affecting master until you're ready. You can think of branches as forks in the history of the project.

there are two kinds of branches in git -- remote branches and local branches. Local branches are the ones that are in your local reposiotry, and remote branches are the ones that are available in the remote repositories. Local branches are, as the name implies, local to the repository, and must be explicitly pushed to the remote repository in order to be visible

the HEAD is a reference to the current branch/commit. It is often used as an implicit argument to git commands.

Creating A New Repository:
git init [--shared]

git init creates a new, completely empty repository, and initializes the .git directory which tracks the repositository state. The --shared option allows members of your group to push to your repository. This is useful when setting up a semi-centralized system where you want other people to push to you.

git clone

git clone REPO creates a new repository that is initialized to the contents of REPO, where REPO is an already existing git repository. It clones the full history, and is able to serve as a standalone repository that can be cloned of itself.

Working With Commits
git commit [-a]

git commit is the command used when done editing. It can be thought as saving a snapshot of the repository, and in many ways is analogous to saving the file in the text editor.

Git needs to be told explicitly which files it should commit. There are 2 common ways of doing this: git add file1 file2 ... will tell git that file1, file2, ... should be committed next time git commit is run, or you could simply run git commit -a which will commit all changes to tracked files in the current directory.

git reset [--hard]

git reset reverts a commit, or uncommitted changes, in case you screwed up. While I may be perfect and never need to use this command (hah), this will come in useful to you guys quite often, when, for example, you commit something completely wrong, or you just decide your edits were no good.

git reset --hard will simply reset your working copy to HEAD, deleting (permanently, so be careful) all the edits since your last commit. This is useful in cases when you broke something and want to try again.

git tag [-a]
git tag attaches a name to a commit for easy reference in the future. It's used to give a commit a name so that it can be referred to easily in the future. Cases when it would be used are when creating a release, or marking a significant point. the -a option allows annotating a tag with extra information for future reference.
git log [[since..]until]
git log shows a list of commit messages from since to until, if given, or a list of all commit messages if not given. It's useful to see the rationale behind a commit, and a summary of changes.
Branching and Merging
git branch [-r] [-d dead-branch]

git branchis the command used to manage the creation and deletion of branches in git.

git branch, when invoked without any arguments, will list all your local branches, marking the current branch with an asterisk (*).

git branch -r will list remote branches, as "subdirectories" of the remote branch.

git branch -d will delete a local branch. This is useful

While git branch can be used to create new branches, I generally avoid using it to create new branches, preferring to use git checkout's -b option, which also switches to the created branch.

git checkout [--track] [-b new [old]] [branch]

git checkout is one of the 2 commands git uses for branch management. It's what I tend to use for branch creation, and it's what is used for switching branches. the --track option is used to cause the branch to follow changes to the head that the branch came from.

git checkout branch is the usual use of this command. It switches from the current branch to branch specified on the command line. branch must already exist within the repository as a branch.

git checkout -b newbranch creates a new branch from the current repository, and switches to it. It does not track the current HEAD.

git checkout -b newbranch remote is often used to create a local version of a remote branch for editing, and switching to it.

git pull [remote] [branch]
git pull essentially pulls the latest version of branch, or all remote branches if none are specified, (from remote if given) and merges it with the current HEAD. it requires all changes to be committed, or it will refuse to merge.
git merge [--no-commit] branch...
git merge will take 2 or more branches and attempt to merge them together using one of many merge strategies. The default generally suffices. After a successful merge, git merge will create a new "merge" commit unless the --no-commit option is given. If this option is given, then the merge is left in an uncommitted state allowing for review.
git cherry-pick [commit]
git cherry-pick will pull one commit from one branch to another branch. This allows trivial bugfixes to be easily moved across branches.
Handling Remote Repositories:
git push [remote [local-branch]

git push pushes your local branches to a remote repository. without any arguments, it pushes the changes to the origin remote.

git push remote will push the current changes to the specified remote repository that you have write access to.

git push remote local-branch pushes the local branch to the remote repository, creating a new remote branch.

git push remote :remote-branch is the method used to delete a remote branch without access to the repository. Be careful, branch deletion is permanent.

git fetch [remote]

git fetch remote will grab the latest changes from remote, but does not modify the working copy. This allows later operations to do something more intelligent than stupidly merging them. For example, you could run git rebase on your branch to replay your changes against the latest remote head.

git rebase upstream [branch]
This will rebase the branch specified (or the current one, if none are specified) against the upstream branch that you specified. What does this mean? It means it takes all your commits, and moves them up so that they're applied off of the new HEAD. Think of it as updating the point that you originally branched from.
git pull [remote]
This command fetches and merges from the specified remote (or origin if none are specified), giving you a merge of your current HEAD and the remote HEAD.
Finding Bugs
git bisect <options>
Git-bisect is a bug-search helper. It lets you specify a known-good revision, known-bad revision, and choses the revisions for you to test next to find the one that caused the bug. Binary search applied to real life, woot!
Example Sessions
Changing Files Already in the Repository

This is most likely the operation you'll be doing the most often. the -a on git commit will tell git to pretend you ran git add on each file that is tracked. Alternatively, you may specify the files you want to commit on the command line.

    $EDITOR my-file         # edit the file
    git commit -a           # commit the changes
Telling git To Track New Files

This set of commands will be needed whenever you create a new file that you want git to track. 

    git add my-new-file     # tell git to track new file
    git commit              # commit the new file
Creating A New Project
    mkdir my-project        # create the project dir
    cd my-project           # cd into it
    git init                # create the git repository
    $EDITOR file file2 ...  # edit/create/move in the initial files
    git add file1 file2 ... # tell git to add the files
    git commit -a           # commit the changes
Creating and Pushing a New Local Branch 
    git checkout -b newbranch   # create the new local branch
    git push origin newbranch   # push branch to remote repository
Branching From a Remote Branch 
    git checkout --track -b mine remote/mine  # that's all it takes
Useful Links