Git Cheat Sheet

Git Basics Rewriting Git History

git init Create empty Git repo in specified directory. Run with no arguments to Replace the last commit with the staged changes and last commit
git commit --amend
<directory> initialize the current directory as a git repository. combined. Use with nothing staged to edit the last commit’s message.

Clone repo located at <repo> onto local machine. Original repo can be git rebase <base> Rebase the current branch onto <base>. <base> can be a commit
git clone <repo>
located on the local filesystem or on a remote machine via HTTP or SSH. ID, a branch name, a tag, or a relative reference to HEAD.
+
git config Define author name to be used for all commits in current repo. Devs Show a log of changes to the local repository's HEAD. Add --relative-
git reflog
user.name <name> commonly use --global flag to set config options for current user. + date flag to show date info or --all to show all refs.

git add Stage all changes in <directory> for the next commit. Replace <directory>
with a <file> to change a specific file.
Git Branches
<directory>

git commit -m Commit the staged snapshot, but instead of launching a text editor, use List all of the branches in your repo. Add a <branch> argument to
git branch
"<message>" <message> as the commit message. create a new branch with the name <branch>.
git checkout -b Create and check out a new branch named <branch>. Drop the -b
git status List which files are staged, unstaged, and untracked.
<branch> flag to checkout an existing branch.
Display the entire commit history using the default format. For
git log
customization see additional options. + git merge <branch> Merge <branch> into the current branch.

git diff Show unstaged changes between your index and working
Remote Repositories +
directory +
git remote add Create a new connection to a remote repo. After adding a remote, you
Undoing Changes <name> <url> can use <name> as a shortcut for <url> in other commands.

git revert Create new commit that undoes all of the changes made in git fetch Fetches a specific <branch>, from the repo. Leave off <branch> to
<commit> <commit>, then apply it to the current branch. <remote> <branch> fetch all remote refs.

Remove <file> from the staging area, but leave the working directory git pull <remote> Fetch the specified remote’s copy of current branch and immediately
git reset <file>
unchanged. This unstages a file without overwriting any changes. + merge it into the local copy. +
Shows which files would be removed from working directory. Use the -f git push <remote> Push the branch to <remote>, along with necessary commits and
git clean -n
flag in place of the -n flag to execute the clean. <branch> objects. Creates named branch in the remote repo if it doesn’t exist. +

Visit atlassian.com/git for more information, training, and tutorials page 1

 Additional Options +
git config git diff
git config --global
user.name <name> Define the author name to be used for all commits by the current user. git diff HEAD Show difference between working directory and last commit.

git config --global

user.email <email>
Define the author email to be used for all commits by the current user. git diff --cached Show difference between staged changes and last commit.

git config --global

Create shortcut for a Git command. E.g. alias.glog "log --graph
alias.<alias-name>
--oneline" will set "git glog" equivalent to "git log --graph --oneline" git reset
<git-command>
git config --system Set text editor used by commands for all users on the machine. <editor>
core.editor git reset Reset staging area to match most recent commit, but leave the working
<editor>
arg should be the command that launches the desired editor (e.g., vi). directory unchanged.
git config --global
Open the global configuration file in a text editor for manual editing. Reset staging area and working directory to match most recent commit
git reset --hard
--edit and overwrites all changes in the working directory.

Move the current branch tip backward to <commit>, reset the staging
git log git reset <commit>
area to match, but leave the working directory alone.

git log -<limit> Limit number of commits by <limit> . E.g. "git log -5" will limit to 5 git reset --hard Same as previous, but resets both the staging area & working directory to
commits <commit> match. Deletes uncommitted changes, and all commits after <commit>.

git log --oneline Condense each commit to a single line. git rebase

git log --stat Include which files were altered and the relative number of lines that git rebase -i Interactively rebase current branch onto <base>. Launches editor to enter
were added or deleted from each of them. <base> commands for how each commit will be transferred to the new base.

git log -p Display the full diff of each commit. git pull
git log git pull --rebase Fetch the remote’s copy of current branch and rebases it into the local
--author="<pattern>" Search for commits by a particular author. <remote> copy. Uses git rebase instead of merge to integrate the branches.
git log
--grep="<pattern>"
Search for commits with a commit message that matches git push
<pattern>.
git log Show commits that occur between <since> and <until>. Args can be a git push <remote> Forces the git push even if it results in a non-fast-forward merge. Do not
<since>..<until> commit ID, branch name, HEAD, or any other kind of revision reference. --force use the --force flag unless you’re absolutely sure you know what you’re doing.

git log -- <file> git push <remote>

Only display commits that have the specified file. Push all of your local branches to the specified remote.
--all

git log --graph Tags aren’t automatically pushed when you push a branch or use the
--graph flag draws a text based graph of commits on left side of commit git push <remote>
--decorate --tags
msgs. --decorate adds names of branches or tags of commits shown. --all flag. The --tags flag sends all of your local tags to the remote repo.

Visit atlassian.com/git for more information, training, and tutorials page 2

Git command examples and explanations
Note: These commands assume you are using Git Bash, and that you have opened the Git Bash console in a work directory containing the files and subfolders
you want to maintain with Git. In these examples, assume the work directory is D:\My Projects\se2030\project1

A. The simple command git init creates an empty local Git repository in your current directory. The .git subfolder that also gets created in your current
directory (as a result of executing this command) is the actual repository – it contains numerous subfolders of its own that are used by Git to maintain
the repository. Never modify or delete the .git subfolder or any of the files within it.

Note: You would only use the command with the optional <directory> specifier (e.g. git init ../project2) to create a Git project in another directory that
is not your current directory.

You use the git init command to create only a local Git repository. You can later connect the local repository to a remote by using the command git
remote add – see note G.

.
B. The command git clone git@bitbucket.org:msoe/project1.git (NOTE the period at the end of this command) creates a non-empty local Git repository
in your current directory that is a copy of a remote repository (on a Bitbucket cloud server) at the url git@bitbucket.org:msoe/project1.git. The .git
subfolder that gets created in your current directory is the local clone of the remote repository.

You use this command to obtain a local copy of the code already stored in a remote repository, so that you can begin collaborating on the project.

This command will FAIL if your local directory is not empty. If you REALLY want to clone a remote repository into a non-empty local directory (and
possibly OVERWRITE anything already in your local directory), you shouldn’t use the clone command. Instead use the following sequence:
git init #create an empty local repository in the local working directory
git remote add origin git@bitbucket.org:msoe/project1.git #tell the local repository to track the remote repository
git fetch #fetch content from remote to local
git checkout –f –track origin/master #force overwrite of local files and synchronize local to remote
C. The git add command primarily does two (different) things based on the state of a file in your working directory.
1. For a file named “myfile.txt” that is not yet being maintained by Git, the git add myfile.txt command tells Git to start tracking the file. Once a file
is being tracked, all subsequent changes to that file can be maintained by Git.
NOTE: If you accidentally start tracking a file that doesn’t need to be tracked (e.g. myfile.bak), you can issue the git rm myfile.bak command to
untrack it.

2. For a file named “myfile.txt” that is already being tracked by Git, the git add myfile.txt command looks at the differences between the file
currently in your working directory and the version of the file that you previously committed to your local Git repository. If differences exist, the
changes are staged to be included in your next commit. See note D.

D. The command git commit –m “I added some comments” commits ALL files that you previously staged for commit with one or more git add commands.
Your local repository is revised to include these latest staged changes, and the reason “I added some comments” is attached to the commit operation.
Any remote repository is left unchanged – until you use git push to synchronize the remote repository with your local repository (see note J).

E. The command git checkout –f is used to force the files in your working directory to be replaced with the files in your local repository, overwriting any
changes you may have made to files in your working directory. Avoid using this command. If you want to replace/restore only a single file (that you may
have accidentally deleted), use git checkout <filename> instead.

F. The command git merge origin/master, used after git fetch (see note H), attempts to merge the contents of your local repository with your working
copy. If the merge cannot be performed automatically, use the git mergetool command (see note M). After merging, use the git add command (see note
C) again, followed by the git commit command again (see note D), followed by git push (see note J).

When you issue the git merge command, the files in your working directory will be automatically modified to include Unified Merge markings (a series of
<<< and >>>sections). These markings indicate how your working file differs from the file in the repository. You can manually modify this file – following
the markers to arrive at a correctly-merged file. However, this is difficult and error-prone. You can instead use a side-by-side visual merge tool to more
easily view the differences and merge the differences correctly. To start the merge tool, issue the command git mergetool.

After merging, use the git add command (see note C) again, followed by the git commit command again (see note D), followed by git push (see note J).
G. The command git remote add origin git@bitbucket.org:msoe/project1.git attaches your local Git repository to the remote repository (on a Bitbucket
cloud server) at the url git@bitbucket.org:msoe/project1.git, identified by the alias “origin”. You would use this command after first using the git init
command to create a local repository which you then want to synchronize with a remote repository.

To view the remotes use

git remote to view all remotes and the aliases that refer to them
git remote show origin to view the status of the remote

H. The command git fetch origin master retrieves the latest updates from the remote repository. This command does not synchronize your local repository
with the remote repository. If the remote repository contains new changes, you can view the differences between your local repository and the remote
repository by using the command git diff master origin/master. If differences exist, you need to use the git merge origin/master command to merge
those changes into your local repository. The git pull (see note I) command essentially combines the git fetch and git merge origin/master commands.

I. The command git pull origin master retrieves the latest updates from the remote repository, and automatically attempts to merge the changes into your
local repository. If the automatic merge fails , use the git mergetool command (see note M).

J. The command git push origin master synchronizes the remote repository with your local repository. This command may fail if the remote repository has
already been updated by someone else. In that case, you have to first issue the git fetch or git pull command (see notes H and I) to synchronize merge
your local repository with the remote repository. After that, then you can try git push again.

K. There are several variants of the git diff command, each of which does something different:
The git diff command shows changes you made in your working directory vs. what you last staged.
The git diff master (or git diff HEAD) command shows changes you made in your working directory vs. what you last committed.
The git diff --cached (or git diff –cached master) command shows changes between what your have staged for commit vs. what you last committed.
The git diff master origin/master command shows between your local repository and the remote repository, since your last push to the remote
repository. NOTE: It does not show differences between your local and the remote if someone else has pushed updates to the remote; to see those,
you have to execute git fetch first.

The git diff commands result it text-based differences to be listed on the Bash console. These may be difficult to interpret. To make viewing differences
easier, you can use a visual difference tool to view side-by-side differences. To use this tool, use the commands above, but replace diff with difftool.
L. The git tag v1.0 command adds the label “v1.0” to a commit so that you can more easily remember the significance of a particular commit – in this case
the tag label “v1.0” may indicate the first fully functional version of your application.
When you tag, the tag label is by default only added to your local repository. To push the label onto the remote repository, you must also issue the
command git push origin –tags

M. The git revert <commit> command is used to undo the changes made in a given commit. It is most easily used when you only have to undo the most
recent commit at HEAD; then it simply replaces the HEAD with the previous commit.

N. The git reset command has several forms, and using the appropriate one is critical, because otherwise this can be a dangerous command to use.
1. The safest use is just git reset or git reset <file>, which simply unstages all files (or a single specified file) from being committed. Use this when
you’ve accidentally used git add on one or more files. One situation where you’d use this would be, for example: you are working on some files,
use git add, and then realize you need to make more changes before staging. Use git reset to unstage the changes so that you can continue
working on the files.

2. A more dangerous version is git reset --hard. In addition to unstaging any staged files, the –hard option causes the content of any files in your
working directory that you’ve modified since the last commit to be reset (overwritten) with the content as of the last commit.

3. Another version is git reset <commit>, which does not touch the files in your working directory, but resets your local repository’s branch tip
(HEAD) to <commit>, and changes the staging area to reflect the differences between your current working directory and the local HEAD. When
you commit locally, your HEAD will update with the version in your working directory. If you subsequently push, you’ll get an error, and you’ll
have to pull first in order to merge your changes.

4. Finally, git reset <commit> --hard, overwrites the files in your working directory with the version from the specified earlier commit. This is the
most dangerous command to use, as you can potentially erase valuable work from your repository. You might want to use this command to
revert back to an earlier version of what was in the repository at the time of the specified commit; this could happen in rare cases where the
contents of the repository got totally broken after the time of the specified commit, and it is just better to go back to that earlier point. Once you
do this reset, you can also reset your team’s remote repository by pushing a hard reset to the remote with git push –f (or git push --force)

Removing unwanted files from your Repository

Sometimes, you may find that you have committed certain files to your repository that you don’t need to be in the repository. This may result from
incorrect (or incomplete) settings in your .gitignore file, or perhaps you just accidentally committed a file that is no longer needed.

There are two cases to consider:

1) You want to completely delete the file both from your working folder and from the repository. This may be the case when you have accidentally
added .class files, or an entire bin/ or out/ folder containing .class files. In this situation, just delete the files from your working folder. Once deleted
from your working folder, git status will indicate that the files are pending deletion from the repository. Use git add, git commit, and git push to
complete the deletion from the repository. To avoid future additions of unwanted files, review your .gitignore file and create a rule to ignore those
files.
2) You want to delete the file ONLY from the repository, but keep it in your working folder. This may be the case if you have accidentally added files
that are critical to the operation of your IDE (e.g. Eclipse, IntelliJ, etc), such as .project, or .idea files. In this situation, don’t delete the files from your
working folder (because your IDE will stop working without them). Instead, use the git rm –cached <file> command, which will stage your file(s) to
be deleted from the repository without deleting them from your working folder. After this command, git status indicates that the files are pending
deletion from the repository. Use git add, git commit, and git push to complete the deletion from the repository. To avoid future additions of
unwanted files, review your .gitignore file and create a rule to ignore those files.