Git‎ > ‎

Typical Usage

Many of these commands are very briefly covered in the Quick Reference. These commands will cover most of the things you'd need for a typical workflow. It assumes you already have a git repository; if not, see Start a Repository.

Add a File

One of the first things you do to a new repository is add files.  First, get into the repository and either copy in your files or use your editor and write new files.  When you are ready, you need to add them to the staging area and then commit them.

# Files can be added individually
git add <file>

# You can add several, or even directories
git add <file1> <file2> <some_directory>

# Keep adding files until you get them all, then check what's being staged
git status

# If that looks right, commit them
git commit

Committing Changes (No Staging)

When you update only a small number of files, you can skip the use of a staging area and commit the files directly using git commit.

# See what files changed
git status

# See the changes in the text files
git diff file1.txt

# Commit three files directly
git commit file1.txt file2.gif

Committing Changes (With Staging)

Using the staging area is really helpful if you have several files that changed, or if you have a couple different tasks that were accomplished that are unrelated and should be split into different commits.

# See what files changed
git status

# Add a couple
git add file1.txt
git add file2.gif

# Add a whole directory at once
git add media_files

# Commit all three at once
git commit

Committing All Changes

I do not recommend this option, but if you blindly want to commit all changes to files that git is already tracking you can do it with git commit -a but please try to not do this.  Often one will commit things that shouldn't go into the repository, plus this command only commits changes and will not add new files that may exist.  Please remember that even though you can do something, it doesn't mean that you should do it.

Sharing History

One of git's strengths is that repositories are completely distributed and everyone has a full copy of all of the history.  It's like having automatic backups and the ability to work offline, but it's incorporated as one of the core principles of the software.

It is likely that you have cloned a repository and you'll typically exchange history with "origin" (the source for the cloned repository).  You keep the history up to date by using git pull to import the changes to the repository and update your working copy of the files.  After working on the codebase, you use git push to send your changes back to origin.

Finding Changes

As shown in examples above, you can see what files were changed by using git status.  This tool also shows what is staged and is about to be committed, as well as identifying new files that are not yet tracked by the repository.  Seeing the differences inside any files can be done with git diff, also shown above.  You can specify a filename with git diff my_file.txt and see just the uncommitted and unstaged changes to that particular file.

To see what commits you have and a remote repository does not yet have, and view this information in a single-line format, try this command:

# See what you need to push to origin
git log origin/master..master

Seeing Historical Information

One can walk backwards in time and view what happened to a file at any point, get any revision of a file, and actually check out a complete copy of the project as it appeared with any commit.

# See a log of changes to the repository, plus see affected files
git log --stat

# See the log of changes for a file
git log my_file.txt

# See the same log, but include the differences between the versions
git log -p my_file.txt

# Show the details of a particular commit
git show eb7d02b4e0af591b82f2dd8bc9cacc62a80865c0

# Show the contents of a file at a particular revision
git show eb7d02b4e0af591b82f2dd8bc9cacc62a80865c0:path/my_file.txt

# Check out a copy of the repository at a commit
git checkout eb7d02b4e0af591b82f2dd8bc9cacc62a80865c0

One important thing to note is that git show needs a path from the top of the repository.  So, even if you are in the/directory/you/need/, you still need to specify the directory on the command line.

You can also search for commits by a particular author or since a given date; there are far too many many options to show here how you can filter and display data differently.  There is even a line-by-line breakdown for finding who changed what sections of a file.

# Search for commits by me
git log --author="Tyler Akins"

# Search for commits starting a week ago
git log --since="1 week ago"

# Search for commits since the day this article was written
git log --since="2012-05-03"

# Show all commits for a single author for the last two weeks
# across all branches, suitable for a code review
git log --since="2 weeks ago" --author="Tyler Akins" -p --reverse -all

# Show who changed what
git blame some_file.txt

For more interesting visualizations, you can try gitk on Linux, gitweb with any browser, or several other tools for a graphical view.

Removing Changes

To remove uncommitted changes and bring back a fresh copy of a file from the repository, use git checkout my_file.txt.  To remove changes that were staged, use git reset HEAD my_file.txt.

Renaming Files

If you wish to move files, git mv old_file.txt new_file.txt will move the file for you and preserve history.  You can follow a file through all of its renames by using git log --follow the_file.txt.

Removing Files

You might have guessed this:  git rm delete_this.txt will delete a file from the repository. In reality, it removes the file from disk and stages the removal from the repository.  You'll still need to commit this change for it to be tracked by the repository.

If you delete the file manually and then try to use git rm, it may give you a warning about removing a non-existent file.  You can either use git checkout delete_this.txt and then git rm delete_this.txt or you can use git rm -f delete_this.txt to force removal of the file from the repository even though it isn't in your working copy.