1. Home
  2. Tutorials
  3. GIT Commands and Examples
Yolinux.com Tutorial
Git logo

GIT Commands and Examples

GIT command summary cheat sheet, use, best practices, tips and examples. This tutorial covers version control with Git using the command line interface, GUI clients and examples which interface Git with GUI diff tools.

rev e3b43d63 rev ec1187f9 rev 60fdba79
git image rev 401 git image rev 402 git image rev 403

Free Information Technology Magazines and Document Downloads
TradePub link image

Free Information Technology Software and Development Magazine Subscriptions and Document Downloads

Git Introduction:

Git is a software source code "Change Management" (CM) system for collaborative development. It maintains a history of file versions. Unlike typical client-server CM systems which "check-out" the latest or a particular version of the files, Git is a distributed CM system where the user has a local copy (a clone) of the entire repository which includes the entire history of all files. The user working with files in their local project work area, interacts with the local clone repository, adding, editing and deleting files and eventually committing their changes. The user can then share these changes to the local repository with a "push" or "pull" to other Git repositories including a server based central "origin" repository.

Git Commands:

Git command summary cheat sheet:

Command Description Man Page
git --help List Git commands git
git --help command Help on given "command" git help
git add path/filename

git add file1 file2 file3
git add --update
git add --all

Add a file or directory to Git CM control. This does not commit the files to the repository but merely adds files to "staging" status.
Must also perform: git commit to enter changes in the repository.
View staged files: git ls-files --stage
Empty directories are not added. Git manages files only.
--update: stage all tracked and modified files.
Undo an add: git reset HEAD path/filename
git add
git blame filename Show file line numbers annotated with author information. Also see git log git blame
git branch -a List all branches (remote and local) git branch
git checkout parentPath/filename
git checkout master
Undo local changes. Revert changes. This directive is misleading as it implies a client-server action. Instead, it relies on the local repo and sets the working copy to the unchanged version, reverting changes.
Checkout "master" will set the local work area to match the master branch.
Also see git reset
git checkout
git clean -df
git clean -df
git -n clean
git -dn clean
Remove files not managed by Git.
-df: All unchecked files and directories are removed.
-n: Dry run. Command not executed.
-d: directories
Clean has nothing to do with an Ant target of "clean" and is in no way related. Also see git gc
git clean
git clone http://git.megacorp.com/git/repo/projectx.git
git clone ssh://user@git.megacorp.com:/srv/git/repo/projectx.git
Copy/clone/create a local repository from the remote repository specified.
[Potential Pitfall]: The following error often is a connectivity issue:
fatal: http://git.megacorp.com/git/repo/projectx.git/info/refs not valid: is this a git repository?
If a proxy error is keeping you from connecting. Fix: unset http_proxy
git clone
git commit
git commit dir-path/filename
git commit -m "Message goes here." filename
Check-in (commit) local staged "working" files into local repository. Files must be staged for commit using git add Files are recursively located and committed into the local git repository. Git commits are Atomic, i.e. all files are committed or none are committed, no incomplete check-in. git commit
git config --global user.name "John Doe"
git config --global user.email jdoe@megacorp.com
This configures ~/.gitconfig git config
git diff
git diff e3b43d63 60fdba79 directory/path
Show file diffs between the working tree and local repo.
Show file diffs between two commits.
git diff
git gc Cleanup unnecessary files and optimize/compress local repo. git gc
git log
git log --oneline
git log directory/path/file
git log --author="name"
git log --graph --decorate --oneline
Show the Git log messages.
--oneline: brief description
--graph --decorate: display branching like gitk except for text terminals.
Note that the letter "q" will quit pagination mode.
git log
git ls-files --stage
git ls-files --cached
git ls-files --modified
git ls-files --others
git ls-files --deleted
git ls-files --unmerged
git ls-files --killed
List files staged.
List cached files.
List modified files.
List other (un-tracked) files.
List deleted files.
List un-merged files.
List killed files that need to be removed due to file/directory conflicts for checkout-index to succeed.
git ls-files
git ls-remote -h http://domain/git/repo/projectx.git HEAD List files under Git control on remote Git server. git ls-remote
git merge branch-name
git merge --abort
Merge a specified branch into your current branch you are in. If you are in the "master" branch, then "branch-name" will be merged into "master". --abort: After starting a merge, you might want to stop the merge and return everything to its pre-merge state.
--stat: Show a diffstat after merge completion
-m: Message to be included in the merge commit
git merge
git mv file-old-name file-new-name Rename a file. Moves/renames file. git mv
git mergetool View file conflicts in a merge tool. Default is vimdiff
Assign a GUI tool:
  • git config --global merge.tool kdiff3
  • git config --global mergetool.kdiff3.cmd 'kdiff3 $LOCAL $BASE $REMOTE -o $MERGED'

  • git config --global merge.tool meld
  • git config --global mergetool.meld.cmd 'meld --diff $LOCAL $BASE $REMOTE --output $MERGED'
    or: meld $LOCAL $MERGED $REMOTE --output $MERGED
    or: meld $LOCAL $BASE $REMOTE --output $MERGED
    (preference of three panes ordered left to right)
Tools options include: p4merge, meld, kdiff3, tkdiff, gvimdiff, vimdiff, ...
git mergetool
git pull origin master Update your local repo and working files with changes posted on the git remote server
origin: refers to repository from which you will receive updates
master: refers to the master branch from which you will receive updates
This command is the same as performing the following two commands:
git fetch
git merge
git pull
git push origin master Update the remote repo from the staged (identified with "git add") local working files
origin: refers to repository from which you will receive updates
master: refers to the master branch from which you will receive updates
This command is the same as performing the following two commands:
git fetch
git merge
git pull
git remote -v Show URL to origin server. git remote
git reset HEAD^ path/filename
git reset HEAD~1 path/filename
git reset --hard HEAD^ path/filename
Remove from staging (local copy of files still modified)
--hard: Don't keep changes, remove modifications to files.
HEAD^: latest commit notation for Linux and bash shell terminals.
HEAD~1: latest commit notation for Microsoft CMD shell. Microsoft DOS shell does not support "^".

Reset the repo to the last good commit specified and ignoring everything after e3b43d63:
git reset --hard e3b43d63
git push –force
Note that using --hard will erase your local work if you have anything stashed.

git reset
git revert HEAD Not an undo but overwrites the commit to reverse changes. git revert
git rm filename
git rm -r directory/path
Delete file from local working index. Don't use the UNIX command rm file-name. Must perform a "git commit" to update the repository.
-n: dry run
-r: recursive removal when given a directory name.
git rm
git status Show tracked files which have been staged, committed, etc. git status
git tag -a April_Sprint -m "Source used for April sprint demo"
git tag -a April_Sprint -m "Source used for April sprint demo" e3b43d63
Add a "tag" to the commit to identify it in human readable terms. You can then push using the following:
git push origin master April_Sprint or
git push origin master --tags
-a: Generate an annotated tag object.
-d: Delete existing tags with the given names.
-f: Replace an existing tag with the given name.
-m: Add a message.
git tag

Where Commit is:

  • HEAD: The latest revision in the repository.
    • HEAD^: latest commit notation for Linux and bash shell terminals.
    • HEAD~1: latest commit notation for Microsoft CMD shell. Microsoft DOS shell does not support "^".
  • BASE: The "pristine" revision of an item in a working copy. Matches checked out version before any modifications.
  • COMMITTED: The last revision in which an item changed before (or at) BASE.
  • PREV: The revision just before the last revision in which an item changed. (Technically, COMMITTED - 1.)

Example Session:

(Assumes that the repository has already been created. For Git repository creation and Git server configuration, see the YoLinux Git server tutorial)
  • Checkout: git clone ssh://user@git.megacorp.com:/srv/git/repo/projectx.git
    copy origin repository and create a local repository.
  • Go to source code directory: cd Projectx/src/main/java/com/megacorp/projectx
  • Edit files:
    • vi file1.java
    • vi file2.java
  • Verify and test: ant
    We are ready to check-in the files into the Git repository.
  • Flag files as staged: git add file1.java file2.java
  • Show status including files staged: git status
  • After many long hours of editing and work, get updates others have made and merge changes with local working files: git pull origin master
  • Resolve merge conflicts if they exist: git mergetool
    At this point, a commit will fail until the merge is resolved.
  • Merge options:
    • Decide on changes you want: git mergetool
      Uses merge tool you specify. Default: vimdiff
    • Choose your file changes: git checkout --ours file1.java
      (--ours: your file in your local work area)
    • Choose their file changes: git checkout --theirs file1.java
      (--theirs: branch you are merging into. The file from remote origin server)
    • Edit the file to remove conflicts: vim file1.java
      (the file will have >>>>>>> and <<<<<<< entries in it)
    • Throw out your changes/abort: git revert HEAD^
      No resolve or check-in necessary if file is reverted.
  • Commit to your local copy of repo: git commit -m "Commit message goes here"
  • Verify and test, again: ant

Ignore files with .gitignore:

There are many files and directories one would like git to ignore and never check-in to the repository. When programming C/C++ one may never want to check-in object (.o) files. Java programmers may never want to check-in ".class" files. IDE's like Netbeans will generate personal configuration settings that one would not want to check-in as they would always conflict with other developers. Git can be configured to ignore these files by generating the file .gitignore in the top directory of your repository.

Example src/projectx.git/.gitignore

Add the following for Netbeans developers:

GIT Properties:

Since the dawn of source code management, change management (CM) systems have supported the notion of enforcing "properties" such as filtering carriage returns (^M), permissions, etc.

End of line (eol) style:

This is especially important for cross platform development as Microsoft development tools will often append a line with CRLF while non-Microsoft tool will typically terminate a line with only a LF. Files edited with Microsoft tools will have a CR which will be displayed as a "^M" with other tools. This may generate unnecessary merge conflicts, ridiculous git diff results, unecessary check-ins due to erroneous git status results and developer hostilities.

The line termination is defined for the entire Git repository by core.autocrlf

This can be set on the server repo:
cd /srv/git/projectx.git/
git config core.autocrlf false
This will set the server configuration file /srv/git/projectx.git/config
        repositoryformatversion = 0
        filemode = true
        bare = true
        sharedrepository = 1
        autocrlf = false
        denyNonFastforwards = true

See the YoLinux.com GIT Server configuration tutorial for more on setting up a Git server.

The line termination rules can be overriden using the .gitattributes file (check-in to your repo in the top directory):
# Auto detect text files and perform LF normalization
*        text=auto         eol=lf

*.cpp    text diff=cpp     eol=lf
*.cs     text diff=csharp  eol=lf
*.vcproj                   eol=crlf
*.java   text diff=java    eol=lf
*.html   text diff=html    eol=lf
*.css    text              eol=lf
*.js     text              eol=lf
*.php    text diff=php     eol=lf
*.module text diff=php     eol=lf
*.engine text diff=php     eol=lf
*.inc    text diff=php     eol=lf
*.sql    text              eol=lf
*.jpg    binary diff=exif
*.gif    binary diff=exif
*.png    binary diff=exif

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=word

# relative paths are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf
  • This configuration "auto detects" text files and also defines C++ files (*.ccp), Java source (*.java), etc as text files.
  • Visual Studio solution files (*.sln) maintain their Microsoft carriage return (cr) followed by a line feed (lf).
  • diff: specifies the git filter to use when viewing a diff that contains changes.
    • exif: Converts binary to a textural representation using exiftool to detect if changes have occurred.
      Configure repo: git config diff.exif.textconv exiftool
  • eol: End Of Line marked by:
    • lf: Unix, Linux, standards based OS, proprietary legacy systems, etc.
    • crlf: DOS and Microsoft OSs
    • cr: Response input scripts, etc
  • merge: Use the option "merge=union" when the solution to merge conflicts are to take lines from both versions, instead of leaving conflict chevron markers.
    One can also specify "-merge" (the opposite, don't merge conflicted lines).

To "normalize" Java source files to LF terminated lines: find ./ -name "*.java" -exec dos2unix {} \;

Executable files:

Files may be marked as having execute permissions by doing the following:

git add script.sh
git update-index --chmod=+x script.sh
git commit -m "Add script"
Note that an improper core.fileMode configuration can change the utility of this action. When set to false, the executable bit differences between the index and the working copy are ignored. Conversely, when set to true, file mode permission changes are considered changes.

GIT Tags:

CM systems such as RCS, CVS and Subversion have all supported tag substitutions and so can Git. Keywords are substituted and will not appear in the file until a new revision of the file is updated from the repository.

The following RCS attribute tags can be set on files stored in GIT. The keyword expansion of the following tags are substituted by a "smudge" filter upon a pull and a "clean" filter on a push. Download the smudge and clean filters.

The following are the supported tags which can be embedded into your source code:
RCS TagExpanded String
$Date$The date as provided by the shell command "date"
$Date: Sun Jul 30 17:21:43 2017 -0700 $
$Author$Will provide the author's name as specified by ~/.gitconfig from the commands:
  • git config --global user.name "John Doe"
  • git config --global user.email john.doe@megacorp.com
$Author: John Doe <john.doe@megacorp.com> $
$Revision$This fills in the Git hash for the commit associated with this revision.
$Revision: 93c4a4a5b871f3183ea90f7df159cc3e363ec534 $
$Source$File name
$File$File name (same as $Source$)
$Id$A summary of the previous 3 keywords: $File, $Date and $Author.

Example source file comment:
Expanded comment:
    $Revision: 93c4a4a5b871f3183ea90f7df159cc3e363ec534 $
    $Author: John Doe <john.doe@megacorp.com> $
    $Date:   Sun Jul 30 17:21:43 2017 -0700 $
    $Source: filename.java $
    $File:   filename.java $
    $Id: filename.java | Sun Jul 30 17:21:43 2017 -0700 | John Doe  $

The personal configuration file ~/.gitconfig is where the filters are assigned. Add the following:
[filter "rcs-keywords"]
	clean  = .git_filters/rcs-keywords.clean
	smudge = .git_filters/rcs-keywords.smudge %f

Place the .gitattributes file and .git_filters/ directory at the root of the CM directory tree:

File: projectx/.gitattributes
*.h    filter=rcs-keywords
*.c    filter=rcs-keywords
*.cc   filter=rcs-keywords
*.cpp  filter=rcs-keywords
*.m    filter=rcs-keywords
*.mm   filter=rcs-keywords
*.java filter=rcs-keywords

Copy the filters to: Allow filters to be executed: chmod ugo+x projectx/.git_filters/rcs-keywords.smudge projectx/.git_filters/rcs-keywords.clean
Otherwise you will get the following error:
fatal: cannot exec '.git_filters/rcs-keywords.clean': Permission denied
error: cannot fork to run external filter .git_filters/rcs-keywords.clean
error: external filter .git_filters/rcs-keywords.clean failed

The filters are checked-in to Git and thus need to have a Git execute attribute applied: git update-index --chmod=+x projectx/.git_filters/rcs-keywords.smudge projectx/.git_filters/rcs-keywords.clean

Note that this tag substitution occurs on a fresh "git clone" or on a "git pull" and modifies the files in your workspace but does not affect the files in the repository itself. The author of the RCS tag edits will not see the substitutions unit they perform a fresh "git clone" to generate a new local repository or when a "git pull" finds file modifications and performs an update.

Graphical diffs and merges for Linux:

Three types of file differences are covered in this section:

  1. Show file differences made since a pull or checkout was made. This shows the changes you have made. It is useful to perform this before a commit.
  2. Show file differences between two files versions stored in Git.
  3. Show differences / conflicts, choose and merge.

Note that the following conventions are used:
  • LOCAL: file on your current local branch
  • REMOTE: branch you are merging to (e.g. new_branch you are trying to pull. Their changes.)
  • MERGED: the partially merged file with merge conflicts marked with chevrons:
    • <<<< HEAD : conflicted lines between this and "=====" are your changes
    • >>>> 7c10716976ee3e9d49f69d71ec6cc4bd43957ec8 : conflicted lines between this and "=====" are their changes in the repository which conflict.
    You have the option of using a merge tool or just editing the file to reflect the changes you want. The chevrons and "=====" must be removed.
  • BASE: the original common ancestor file from which LOCAL and REMOTE evolved. The file before the conflicted changes.

1) File differences since last pull:

Git uses the command line Linux "diff" command. A GUI diff tool is far more intuitive and can be specified using the following commands:
  • Configure git to use a GUI diff tool:
    • git config --global diff.tool meld
    • git config --global difftool.meld.cmd 'meld $LOCAL $REMOTE'
    This adds the following entry to your ~/.gitconfig
            tool = meld
    [difftool "meld"]
            cmd = meld $LOCAL $REMOTE
  • GUI diff between file in working area and repo: git difftool filename.java
    Viewing (1/1): 'filename.java'
    Launch 'meld' [Y/n]: y

2) File differences between two revisions:

  • View the differences for a file and two commits back: git difftool HEAD HEAD^^ filename.java
  • View the differences for a file between two commits: git difftool a1a1c14299049c5e1cf60f8cc02f41bbf7d8b85f 93c4a4a5b871f3183ea90f7df159cc3e363ec534 filename.java
    (Use "git log" to view the commit hashes)
  • View the differences for two files between two commits: git difftool a1a1c14299049c5e1cf60f8cc02f41bbf7d8b85f:file1.java 93c4a4a5b871f3183ea90f7df159cc3e363ec534:file2.java
  • View all differences between two commits: git difftool a1a1c14299049c5e1cf60f8cc02f41bbf7d8b85f 93c4a4a5b871f3183ea90f7df159cc3e363ec534
    Viewing (1/3): 'file_1.java'
    Launch 'meld' [Y/n]: y
    Viewing (2/3): 'file_2.java'
    Launch 'meld' [Y/n]: y
    Viewing (3/3): 'file_3.java'
    Launch 'meld' [Y/n]: y

3) Conflicts and merges:

Configure git to use a GUI merge tool. Note that most diff tools also support merges:
  • git config --global merge.tool meld
  • git config --global mergetool.meld.cmd 'meld $LOCAL $MERGED $REMOTE'
This adds the following entry to your ~/.gitconfig
        tool = meld
[mergetool "meld"]
        cmd = meld $BASE $LOCAL $REMOTE --output $MERGED

Merge conflicts occur when two developers check out common files and both edit the same line/lines. Edits to different lines merge automatically and cleanly. When changes are made to the same line and then one developer commits and pushes the code, the second developer must deal with the merge conflicts by selecting the line they want, "ours" or "theirs". GUI merge tools support the management of a merge by addressing the lines marked as a conflict using the text markers ">>>>".

List of graphical diff and merge tools:

  • tkdiff: [download]
  • gtkdiff: Has diff3 and merge features. Written with GTK+. After gtkdiff-0.8.0, GNOME desktop required.
  • diffUse: Diff/merge GUI tool. Good line matching features. Supports Unicode.
  • kdiff3: Graphical directory and file diff, merge and edit. KDE3/Qt based. (Cross platform) MS/Windows download available. A very good directory and file diff and merge tool.
    • Diff:
      • git config --global diff.tool kdiff3
      • git config --global difftool.kdiff3.cmd 'kdiff3 $LOCAL $REMOTE'
        This adds the following entry to your ~/.gitconfig
                tool = kdiff3
        [difftool "kdiff3"]
                cmd = kdiff3 $LOCAL $REMOTE
    • Merge:
      • git config --global merge.tool kdiff3
      • git config --global mergetool.kdiff3.cmd 'kdiff3 $BASE $LOCAL $REMOTE -o $MERGED'
        This adds the following entry to your ~/.gitconfig
                tool = kdiff3
        [mergetool "kdiff3"]
                cmd = kdiff3 $LOCAL $BASE $REMOTE -o $MERGED
  • Kompare: Ships with (RHEL6/RHEL5/RHEL4/FC3+) KDE SDK. [manual]
    Included in Red Hat RPM package "kdesdk" an Ubuntu package "kompare".
    [Potential Pitfall]: RPM installation error:
    error: Failed dependencies:
            perl(DCOP) is needed by kdesdk-3.5.4-3.el5.i386 
    Solution: Install the dependency package "kdebindings".
  • mgdiff: Motif-based graphical file difference browser and merge. Comes with S.u.S.E. distro.
  • Meld: Compare, edit and merge.
    • Diff:
      • git config --global diff.tool meld
      • git config --global difftool.meld.cmd 'meld $LOCAL $REMOTE'
        This adds the following entry to your ~/.gitconfig
                tool = meld
        [difftool "meld"]
                cmd = meld $LOCAL $REMOTE
    • Merge:
      • git config --global merge.tool meld
      • git config --global mergetool.meld.cmd 'meld $BASE $LOCAL $REMOTE --output $MERGED'
        This adds the following entry to your ~/.gitconfig
                tool = meld
        [mergetool "meld"]
                cmd = meld $LOCAL $BASE $REMOTE --output $MERGED
  • xxdiff: Compare 2 or 3 files and merge. Also compares directories.
  • gvim and gvimdiff
  • Beyond Compare - commercial tool (cross platform)

GIT GUI interfaces for Linux:

Git comes with a GUI: git gui and a browser tool gitk
(Ubuntu: sudo apt-get install git-gui)

For other options see:
  • CollabNet: GitEye: cross platform, push/pull, history, diffs, revert, stash, etc. Intuitive and customizable
  • SmartGit: cross platform commercial product
  • QGit: View revisions, diffs, files history, files annotation, archive tree, Commit changes visually cherry picking modified files.
  • Axosoft: GitKraken: commercial product. Free for non-commercial use. Cross platform.
  • Git-cola: Python git front-end. (cross platform)
  • GNOME: Giggle: GTK+ application
  • GNOME: gitg

Web Clients:


  • nautilus-git: GNOME Nautilus/Nemo file browser GIT plug-in.
  • EGit Eclipse IDE plug-in
Note: A GIT client is built into many of today's development IDEs such as NetBeans.

Git Best Practices:

  • ALWAYS compile and test before pushing source code to the origin server. Developers expect shared changes to compile.
  • Always add commit comments. Nothing is more obnoxious that looking at an uninformative log or information history.
  • Monstrous binary files like CD or DVD ISO images are better suited for storage on a file system rather than in Git. Git will not be able to show differences between version and will be slower than a raw filesystem.
  • Don't copy, rename and move directories and files with system shell commands. Use Git commands to "rm", "mv", and "add" files and then commit changes when done. Work within Git.
  • Push changes as a single logical change-set for one purpose. Thus all code changes for a single bug fix or enhancement should be checked-in together. This allows one to better follow the history log of changes.
    • Stage code at the directory level and all changed files, recursively in the directory and sub-directories will be checked in together.
      git add -all
    • Stage files together by specifying them explicitly:
      git add file.cpp file2.cpp ...
  • Tie Bug tracking and Git CM together:
    • Use comments when commiting files into Git. Add bug tracking numbers to the comments so Git will reference Trac bugs.
    • If using Trac, add Trac comments so that links are generated to the Git repository by placing the Git revision hash in square braces (i.e. [e3b43d63]) in a Trac comment. In this way, Trac will have a direct URL link to Gitweb.
  • If using Trac integrated with Git, refer to the Trac ticket in the Git commit comment using a "#" in front of the Trac ticket number (e.g. #65) This generates a hyperlink when the Git logs are viewed in Trac.
  • Documentation and related artifacts checked-in to Git should not be under the source tree but parallel to it. This isolates the source tree so that email notification triggers sent to developers upon source changes will only go out on source changes or regression build and test systems like Jenkins or Cabie will only rebuild and test on source changes rather than on unrelated documentation changes.


Using Eclipse IDE with Git:

Block Eclipse from viewing the hidden ".Git/" directory so that Eclipse does not intrude or alter their contents:
  • Select the toolbar options: "Project" + "Properties"
  • Select the "Java Build Path" + select the "Source" tab
  • Select the "Excluded" item and select "Edit"
  • In the lower half under "Exclusion patterns:" select "Add..." and enter the pattern **/.git/*

Eclipse IDE configuration to exclude .git/ directories



Distributed Version Control with Git [Kindle Edition]
Lars Vogel (Author)
A practical introduction into the Git version control system.

Version Control with GIT
by Jon Loeliger and Matthew McCullough
ISBN #1449316387, O'Reilly Press

Pro Git
Scott Chacon (Author)
Visual explanations of the git concepts and methodology.

Step-by-step ways to track, merge, and manage software projects, using Git.



    Bookmark and Share