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
# If that looks right, commit them
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
# See what files changed
# See the changes in the text files
git diff file1.txt README.md
# Commit three files directly
git commit file1.txt file2.gif README.md
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
# Add a couple
git add file1.txt
git add file2.gif README.md
# Add a whole directory at once
git add media_files
# Commit all three at once
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
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
to import the changes to the repository and update your working copy of the files. After working on the codebase, you use
to send your changes back to origin.
As shown in examples above, you can see what files were changed by using
. 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
, 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
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.
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
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
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
, it may give you a warning about removing a non-existent file. You can either use
git checkout delete_this.txt
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.