The Cheatsheet discusses Git commands for daily use. Many Git commands are available from the command line. Git offers rich features for version control, collaboration, and project management. You can explore more Git commands and options in the official Git documentation.
5-30 Minutes to read
New to Git?
Four words used on nearly every line of this page:
- Repository
-
is the folder that holds your project and the complete history of every change ever made to it.
- Commit
-
is a saved snapshot of your project at one moment in time. Every commit gets its own identifier, called a hash, for example
4b4690d00. - Branch
-
is a separate line of work inside the same repository. You can try something out on a branch without touching the stable version.
- Remote
-
is a copy of your repository that lives somewhere else, normally on a server such as GitHub. The default name for that copy is
origin.
Status colors
In the Git version control system, the output of the git status command can be displayed with different colors to provide visual cues about the state of your repository. The colors help you quickly identify modified, added, deleted, or untracked files, among other things. The specific colors used can depend on your terminal configuration, but here are the default colors commonly used by Git:
Git does not give every kind of change its own color. The color answers one question only: is this change already staged for the next commit, or not? Adding, changing, renaming and deleting all follow that same rule:
-
Staged changes are shown in green. Git lists them under the heading
Changes to be committed:. A brand new file you just picked up withgit add, a changed file, a renamed file and a deleted file all turn green once they are staged. -
Changes that are not staged yet are shown in red. Git lists them under the heading
Changes not staged for commit:. -
Untracked files are shown in red as well, under the heading
Untracked files:. These are files Git does not know about yet. -
Unmerged files (files with a merge conflict) are shown in red, under the heading
Unmerged paths:.
| The same file can show up twice, once in green and once in red. That happens when you stage a file and then keep editing it. The green entry is what goes into your next commit, the red entry is what you would still have to add. |
It’s important to note that the actual colors displayed may vary depending on your terminal configuration and settings. You can customize the colors used by Git by modifying your terminal’s color scheme or configuring Git-specific color options in your Git configuration file (~/.gitconfig).
[color "status"]
header = normal
added = green
changed = red
untracked = red
unmerged = red
branch = greenGit understands only a fixed set of names in this section. The useful ones are header (the text around the file names), added (changes that are staged), changed (changes that are not staged), untracked, unmerged and branch. Every other name is ignored without a warning.
For the value, Git accepts normal, black, red, green, yellow, blue, magenta, cyan and white. Current Git versions also accept a number from 0 to 255 or a hex value such as #ff8800.
| Files ignored by |
| Color | Description |
|---|---|
| A change that is already staged, printed under |
| A change that is not staged yet ( |
| The plain text Git prints around the file names, for example the section headings and the hints below them. |
Aliases
Git aliases allow you to create shortcuts or alternative names for Git commands and workflows, making it easier and faster to execute common operations. You can define aliases in your personal Git configuration file ~/.gitconfig, either globally for all repositories or locally for a specific repository.
[alias]
ad = add .
br = branch
cs = commit --amend --no-edit
ce = commit --amend
cr = reset HEAD~1 --soft
cd = reset HEAD~1 --hard
cl = clone
ck = checkout
df = diff
dw = diff --word-diff
he = help
hi = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
la = ls-files
ll = ls-tree --full-tree -r --name-only HEAD
lg = log --stat
pu = push
rc = rm -r --cached .
rf = rm -rf --cached .
st = status
ty = cat-fileCommon Commands
Find some already prepared Git commands used quite often.
Clearing the index
The commands below will remove all of the items from the Git index (not from the working directory or local repo) and then (re-)update from local folder ..
git rm -r --cached . && git add .or forced
git rm -rf --cached . && git add .Commit commands
The git commit command is used to record changes to the repository. It creates a new commit that includes the changes you have made to your files. Commits serve as snapshots of the repository at a specific point in time and form the basis of the Git version control system.
Here’s what each part of the command means:
-
-m <commit_message>, this option allows you to provide a commit message describing the commit changes made. The commit message should be concise but informative, summarizing the purpose or nature of the changes.
Additionally, you can use various options and flags with the git commit command to modify its behavior. Some commonly used options include:
-
-a, automatically stages all modified files before committing. -
-am <commit_message>, combines the-aand-moptions, allowing you to automatically stage modified files and provide a commit message in a single command. -
-p, interactively selects and commits changes from specific hunks within modified files.
To make a commit, you typically follow these steps:
-
Make changes to your files in the repository using any text editor or IDE.
-
Use the git add command to stage the changes you want to include in the commit. The add option tells Git which files should be part of the commit. For example, you can use git add
.(dot) to stage all changes in the current directory. -
Once you have staged the changes, use the git commit command to create a new commit. Provide a meaningful commit message using the
-moption.
After executing the commit command, Git will create a new commit with your staged changes. The commit will be assigned a unique identifier, a SHA-1 hash, and added to the repository’s commit history.
| Command | Description | Example |
|---|---|---|
| Display a list of files in your staging directory with accompanying file status. | |
| Stage file changes. Running this command with an associated file name will stage the file changes to your staging directory. | Stage all files in the current folder, indicated by |
| Save changes to your Git repository. Running this command with an associated file name will save the file changes to your repo. | |
| Add all modified and deleted files in your working directory to the current commit. | |
| Amend a Git commit. Edit a Git commit message by adding a message in quotation marks after the command. | |
| Add a Git commit message. Add your message in quotation marks following the command. | |
| Combine options | |
| Command | Description | Example |
|---|---|---|
| Commit when files are cleaned. No files are changed but some deleted. | |
| Commit a specific version. | |
| Commit a specific version but no (file) changes applied. | |
| Commit a specific version but changes are not final. | |
| Commit latest changes but no specific reason given. | |
Checkout Commands
The git checkout command is used to switch between branches, create new branches, or restore files to a previous state.
Since Git 2.23 two newer commands split this work into clearer parts: git switch only changes the branch, and git restore only brings files back. git checkout still works and you will meet it everywhere, so it is worth knowing, but for new work git switch develop reads more clearly than git checkout develop.
| Detached HEAD state In Git, the detached HEAD state refers to a situation where the currently checked out commit is not associated with a branch. Instead of being on a branch, the HEAD points directly to a specific commit. When you typically work on a branch in Git, the HEAD is associated with that branch, and any new commits you create will be added to the branch’s history. However, in a detached HEAD state, any new commits you create will not be part of any branch. The HEAD points directly to the commit. |
| Command | Description | Example |
|---|---|---|
| Switch to a different branch. | |
| Create a new branch and switch to it. | |
| Create a local branch from a remote (branch) and checkout that branch. | |
| Checkout from a previously created (existing) commit. | |
| Checkout from a previously created (existing) commit | |
| Checkout a branch based on a tag in a detached HEAD state. | |
| Checkout a new local branch | |
Create a new repository on the command line
git init
git add README.md
git commit -m "initial commit"
git remote add origin https://github.com/jekyll-one-org/my_heroku_starter_app.git
git push -u origin mainAdd file permissions on Windows
Change file permissions Unix-style (chmod) when you are on Windows. This may be helpful when shell scripts are created and execute rights need to be stored in the repo.
git update-index --chmod=+x 'name-of-shell-script'| See for more details on Change file permissions when working on windows |
Disable warning CRLF will be replaced by LF
You can turn off the warning with:
git config --global core.safecrlf false| This will only turn off the warning, not the function itself. |
Branch Commands
Git is a distributed version control system that allows you to manage multiple code branches within a repository. A branch in Git is used to keep your changes until they are ready. You can do your work on a branch like develop while the main branch (main) remains stable (unchanged). After you are done (on the branch develop for example), you can merge the changes into the main branch for a new stable version.
The sections below take the branch commands from Branch Commands once more, this time as short recipes for single jobs: listing, renaming, creating, publishing and deleting a branch.
List branches
git branch -a lists all branches, the local ones and the remote ones. git branch -r lists the remote branches only.
git branch -a
git branch -rRename a branch
If you want to rename a local branch while pointed to any branch, do:
git branch -m <oldname> <newname>If you want to rename the current local branch, you can do:
git branch -m <newname>If you want rename a the local branch and push|reset the upstream branch:
git push origin -u <newname>
git push origin --delete <old_name>Push current branch to remote
When you create a branch on your own machine, the server does not know about it yet. The option --set-upstream (short form -u) pushes the branch to the remote and remembers the two branches as a pair. After that, a plain git push or git pull is enough as long as you are on that branch.
git push --set-upstream origin mainCreate branches
Create a branch on your local machine and switch in this branch:
git checkout -b <name_of_your_new_branch>| Git does not allow creating a (new, isolated) branch on a remote repository. Instead, you can push an existing local branch and thereby publish it on a remote repository. |
Delete branches
A branch that is merged, or that was only a short experiment, can be deleted. Deleting a branch does not delete your commits, it only removes the name that pointed to them. A branch normally exists twice, once on your own machine (local) and once on the server (remote). Each copy has to be deleted on its own.
Delete a branch from a remote repository
To delete a branch on the server, push the deletion with the option -d (long form --delete). The branch disappears for everybody else the next time they run git fetch or git pull.
git push -d <remote_name> <branch_name>| In most cases the remote name is origin. In such a case you’ll have to use the command like so. |
git push -d origin <branch_name>Delete a branch from your local repository
To delete a branch on your own machine, use git branch -d. Git refuses to delete a branch that still holds work not merged anywhere else. If you are sure you want to lose that work, use the capital -D instead. You cannot delete the branch you are standing on, so switch to another branch first.
git branch -d <branch_name>Create branch from commit
Create a branch from a previous commit:
git branch branch_name <sha1-of-commit>Summary of branch commands
| Command | Description | Example |
|---|---|---|
| Display a list of local branches in your repository. | |
| Display a list of both local and remote branches in your repository. | |
| Delete a local branch. This will not work if the branch to delete has unmerged changes. | |
| Delete a local branch with unmerged changes. | |
| Rename a local branch. | |
| Rename the current local branch | |
| Display a list of remote branches in your repository. | |
| Delete a remote branch. | |
| Set an upstream branch. Running this command will push your local branch to the new remote branch and remember the two as a pair. From then on a plain | |
Cherry Pick Commands
The git cherry-pick command is used to apply specific commits from one branch to another. It lets you pick individual commits and apply them to the current branch.
| The cherry pick command can be helpful if you accidentally make a commit to the wrong branch. Cherry picking allows you to get those changes onto the correct branch without redoing any work. After the commit has been cherry picked, you can either continue working with the changes before committing, or you can immediately commit the changes onto the target branch. |
The command takes changes from a target commit and places them on the HEAD of the currently checked out branch. From here, you can either continue working with these changes in your working directory or you can immediately commit the changes onto the new branch.
| Some commonly used |
| Command | Description | Example |
|---|---|---|
| Apply a commit’s changes onto a different branch. | |
| Apply changes from multiple commits to the current branch. The commits are applied in the order specified. | |
| Perform a no commit cherry-pick, which applies the changes from the specified commit but does not create a new commit. This allows you to modify the changes before committing them. | |
| Opens the commit message editor before committing the cherry-picked changes. It allows you to modify the commit message. | |
| Continues the cherry-pick process after resolving any conflicts that occurred during the cherry-pick operation. | |
| Aborts the cherry-pick operation and returns the branch to its original state before the cherry-pick was started. | |
Clone Commands
The git clone command creates a copy of a Git repository in a new directory. It retrieves the entire repository, including all its files, branches, and commit history.
| Command | Description | Example |
|---|---|---|
| Clone a specified remote repository. | |
| Clone a repository and name the local directory. | |
| Clone a repository and name the remote ( | |
| Clone a repository and checkout the specific branch. | |
| Clone a repository with a specified number of commits ( | |
| Clone a repository without copying the repo’s tags. | |
Here’s what each part of the command means:
-
<repository_url>, this is the repository URL you want to clone. It can be a remote repository URL (e.g., on GitHub or GitLab) or a local path to a repository. -
<directory_name>(optional), this is the directory name where the repository will be cloned. Git will create a new directory using the repository’s name if not specified.
Config Commands
Git config commands configure various aspects of Git, such as user information, default behavior, aliases, etc. Here are some commonly used Git config commands:
| Command | Description | Example |
|---|---|---|
| Sets the email address associated with your Git commits and other Git actions. | |
| Sets the user name associated with your Git commits and other Git actions. | |
| Sets the text editor Git should use when creating commit messages. Replace | |
| Lists all the Git configuration settings currently set on your system. | |
| Opens the Git configuration file from the current repo ( | |
| Opens your personal Git configuration file ( | |
| Opens the Git application configuration file ( | |
Merge Commands
When using Git, several commands are available to perform a merge operation. The most commonly used commands for merging branches are git merge and git pull (see Pull Commands).
| These are the basic commands for merging branches in Git. There are more options and flags that change the way they behave. See the official Git documentation for the full list, and for the situations in which each way of merging works best. |
Here’s an overview of these commands:
| Command | Description | Example |
|---|---|---|
| Combine two or more development histories together. Used in combination with fetch, this will combine the fetched history from a remote branch into the currently checked out local branch. | |
| Merge changes from one branch into the branch you currently have checked out. | |
| Aborts the merge process and restores the project’s state to before the merge was attempted. This works as a failsafe when a conflict occurs. | |
| Attempt to complete a merge that was stopped due to file conflicts after resolving the merge conflict. | |
| Combine all changes from the branch being merged into a single commit rather than preserving them as individual commits. | |
| Combine branch into the current branch, but do not make a new commit. | |
| Creates a merge commit instead of attempting a fast-forward. | |
Pull Commands
The git pull command fetches and merges changes from a remote repository into the current branch. Here’s an overview of the pull command and its commonly used options:
| Command | Description | Example |
|---|---|---|
| This command fetches, and merges changes from the remote repository into your current local branch. | |
| Suppress the output text after both | |
| Expand the output text after both | |
Commands related to a merge
When performing a git pull command, you typically fetch and merge the latest changes from a remote repository into your current branch. Here are some common scenarios related to merging during a pull:
-
git pull --squash– Combine all changes from the branch being merged into a single commit, rather than preserving the individual commits. -
git pull --no-commit– Merge the changes from the remote branch, but stop just before the merge commit is made, so you can check the result and commit it yourself. -
git pull --no-ff– Create a merge commit in all cases, even when the merge could instead be resolved as a fast-forward.
Commands related to a fetch
When using Git, the git pull command fetches and merges changes from a remote repository into your local repository. It combines the git fetch command (to retrieve the latest changes from the remote repository) with the git merge command (to incorporate those changes into your local branch).
Here are some git pull commands and related options you can use in different scenarios:
-
git pull --all– Fetch all remotes. -
git pull --depth=<depth>– Fetch a limited number of commits. -
git pull --dry-run– Show the action that would be completed without actually making changes to your repo. -
git pull --prune– Remove all remote references that no longer exist on the remote. -
git pull --no-tags– Do not fetch tags.
Push Commands
The git push command uploads local repository commits to a remote repository. It is used to share your changes with others or to update a remote repository with your latest work. Here’s an overview of the push command and its commonly used options:
| A safer way to force a push
Never force push to a shared branch such as |
| Command | Description | Example |
|---|---|---|
| Push the current checked out branch to the default remote | |
| Push the specified local branch along with all of its necessary commits to your destination remote repository. | |
| Force a Git push in a non-fast-forward merge. This option forces the update of a remote ref even when that is not the ancestor of the local ref. This can cause the remote repository to lose commits, so use with care. | |
| Push all local branches to a specified remote. | |
| Push all local tags to a specified remote ( | |
Rebase Commands
The git rebase command integrates changes from one branch onto another. It allows you to modify the commit history of a branch by moving, combining, or deleting commits.
| The command |
Here are some commonly used Git rebase commands:
| Command | Description | Example |
|---|---|---|
| Rebase your currently checked out branch onto a target branch. This rewrites a commit(s) from the source branch and applies it on the top of the target branch. | |
| Proceed with a Git rebase after you have resolved a conflict between files. | |
| Skip an action that results in a conflict to proceed with a Git rebase. | |
| Cancel a Git rebase. Your branch will be back in the state it was before you started the rebase. | |
| Initiate interactive rebase from your currently checked out branch onto a target branch. | |
Stash Commands
Git stash is a command that temporarily saves changes you have made to your working directory so that you can switch to a different branch or apply the changes later.
| Stashing is useful when switching branches or temporarily setting aside your changes without committing them. It allows you to work on different tasks or switch contexts without losing your current work. |
Here are some commonly used stash commands:
| Command | Description | Example |
|---|---|---|
| Create a stash with local modifications and revert back to the head commit. | |
| Display a list of all stashes in your repository. | |
| View the content of your most recent stash. This will show your stashed changes as a diff between the stashed content and the commit from back when the stash was created. | |
| Remove a stash from the list of stashes in your repository. | |
| Apply a stash to the top of the current working tree and remove it from your list of stashes. | |
| Apply a stash on top of the current working tree. The stash will not be removed from your list of stashes. | |
| Remove all stashes from your repository. | |
Reset, Publish and Cleanup Commands
The sections below help on the days when something went wrong, or when a project is published for the first time: going back to an earlier commit, connecting a local project to a server, and removing files Git does not track.
Reset repo to a commit
Sometimes the last commits turn out to be a mistake and you want the project back the way it was at an earlier point. git reset --hard does that. It moves the current branch back to the commit you name and drops everything that came after it. Run git log first to find the hash of the commit you want.
| The option |
Reset your local repository
Name the commit you want to return to. The branch on your machine is moved back to that commit, and your files are set back to the state they had at that time.
git reset --hard 217a618Update the remote repository
After a reset, your local branch is behind the branch on the server and a normal git push is refused. The option --force tells Git to overwrite the remote branch with your shorter history. This removes those commits for everybody, so only do it on a branch nobody else uses, and prefer --force-with-lease (see Push Commands).
git push --force origin mainPush an existing repository from the command line
Use these commands when a project already exists on your machine but not yet on a server. Create an empty repository on the server first. git remote add stores the server address under a short name, here github, and git push -u uploads your branch and remembers the pair, so later a plain git push is enough.
git remote add github https://github.com/jekyll-one-org/heroku_starter_app.git
git push -u github mainRemoving non-repository files with git
If you want to see which files will be deleted you can use the option -n before you run the actual command:
git clean -nYou can use git-clean. This command will remove untracked files/directories. By default, it will only print what it would have removed, without actually removing them.
Given the -f flag to remove the files, and the -d flag to remove empty directories as well:
git clean -dfAlso removing ignored files:
git clean -dfxTag Commands
A tag is a fixed name for one single commit, normally used to mark a released version such as v2023.4.2. Unlike a branch, a tag never moves to another commit.
Delete a Git tag
Use the git 'tag' command with the '-d' option
git tag -d v2023.4.2git push -d origin v2023.4.2Set a Git tag
When modifying remember to issue a new tag command in git before committing, then push the new tag
git tag -a v2023.4.2 -m "v2023.4.2"
git push origin --tagsIndex and File Commands
The index (also called the cache or the staging area) is the list of files Git will put into your next commit. The section below shows how to look at the files Git knows about.
List all committed files
List all files in the repo, including those that are only staged but not yet committed:
git ls-filesLists all of the already committed files being tracked by the repo:
git ls-tree --full-tree -r --name-only HEAD