Jekyll One

Fulltext Search

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 with git 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    = green

Git 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 .gitignore get no color, because git status does not list them at all. Use git status --ignored to see them. Git also prints colors only when the output goes to a terminal, so a command such as git status > out.txt gives you a plain text file without color codes.

Table 1. Default color scheme of git status
Color Description

green

A change that is already staged, printed under Changes to be committed:. New, changed, renamed and deleted files all look the same here.

red

A change that is not staged yet (Changes not staged for commit:), an untracked file (Untracked files:), or a file with a merge conflict (Unmerged paths:).

normal

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-file

Common 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 ..

Clear the index and re-add all files
git rm -r --cached . && git add .

or forced

Clear the index forced and re-add all files
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 -a and -m options, 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:

  1. Make changes to your files in the repository using any text editor or IDE.

  2. 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.

  3. Once you have staged the changes, use the git commit command to create a new commit. Provide a meaningful commit message using the -m option.

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

status

Display a list of files in your staging directory with accompanying file status.

git status

add

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 . (dot)

git add .

commit

Save changes to your Git repository. Running this command with an associated file name will save the file changes to your repo.

git commit

commit -a

Add all modified and deleted files in your working directory to the current commit.

git commit -a

commit --amend -m "New commit message"

Amend a Git commit. Edit a Git commit message by adding a message in quotation marks after the command.

git commit --amend -m "New commit message"

commit -m "message text"

Add a Git commit message. Add your message in quotation marks following the command.

git commit -m "message text"

commit -am "message text"

Combine options a and m to add all modified and deleted files and provide a commit message in a single command.

git commit -am "message text"
Command Description Example

commit -am "Cleanup files"

Commit when files are cleaned. No files are changed but some deleted.

git commit -am "Cleanup files"

commit -am "New version 2026.1.3"

Commit a specific version.

git commit -am "New version 2026.1.3"

commit --allow-empty -m "New version 2026.1.3"

Commit a specific version but no (file) changes applied.

git commit --allow-empty -m "New version 2026.1.3"

commit -am "Prepare new version 2026.1.3"

Commit a specific version but changes are not final.

git commit -am "Prepare new version 2026.1.3"

commit -am "Latest files"

Commit latest changes but no specific reason given.

git commit -am "Latest files"

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

checkout <branch-name>

Switch to a different branch.

git checkout main

checkout -b <branch-name>

Create a new branch and switch to it.

git checkout -b develop

checkout -b <branch-name> <remote-name>/<branch-name>

Create a local branch from a remote (branch) and checkout that branch.

git checkout -b dummy origin/dummy_branch

checkout <commit hash>

Checkout from a previously created (existing) commit.

git checkout 4b4690d00

checkout -b <branch-name> <commit hash>

Checkout from a previously created (existing) commit <commit hash> to a new local branch <branch-name>.

git checkout -b new_branch 4b4690d00

checkout <tag name>

Checkout a branch based on a tag in a detached HEAD state.

git checkout v2023.2.6

checkout -b <branch-name> <tag-name>

Checkout a new local branch <branch-name> based on a tag.

git checkout -b b2023.2.6 v2023.2.6

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 main

Add 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 -r

Rename 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 main

Create 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

branch

Display a list of local branches in your repository.

git branch

branch -a

Display a list of both local and remote branches in your repository.

git branch -a

branch -d <branch-name>

Delete a local branch. This will not work if the branch to delete has unmerged changes.

git branch -d dummy_branch

branch -D <branch-name>

Delete a local branch with unmerged changes.

git branch -D dummy_branch

branch -m <branch-name> <new-branch-name>

Rename a local branch.

git branch -m master main

branch -m <branch-name>

Rename the current local branch

git branch -m main

branch -r

Display a list of remote branches in your repository.

git branch -r

push <remote> --delete <remote branch>

Delete a remote branch.

git push origin --delete dummy_branch

push --set-upstream <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 git push or git pull is enough for that branch.

git push --set-upstream origin dummy_branch

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 cherry-pick commands allow you to apply commits from one branch to another selectively. It is important to note that cherry-picking can introduce conflicts, especially if the same changes have been made in different branches.

Command Description Example

cherry-pick <commit_hash>

Apply a commit’s changes onto a different branch.

git cherry-pick <commit_hash>

cherry-pick <commit_hash1> <commit_hash2>

Apply changes from multiple commits to the current branch. The commits are applied in the order specified.

git cherry-pick <commit_hash1> <commit_hash2>

cherry-pick -n <commit_hash>

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.

git cherry-pick -n <commit_hash>

cherry-pick --edit <commit_hash>

Opens the commit message editor before committing the cherry-picked changes. It allows you to modify the commit message.

git cherry-pick --edit <commit_hash>

cherry-pick --continue

Continues the cherry-pick process after resolving any conflicts that occurred during the cherry-pick operation.

git cherry-pick --continue

cherry-pick --abort

Aborts the cherry-pick operation and returns the branch to its original state before the cherry-pick was started.

git cherry-pick --abort

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 <repository-url>

Clone a specified remote repository.

git clone <repository-url>

clone <repository-url> <directory-name>

Clone a repository and name the local directory.

git clone <repository-url> <directory-name>

clone <repository-url> --origin <name>

Clone a repository and name the remote (<name>). If you do not wish to name the remote, Git will provide the default name origin.

git clone <repository-url> --origin <name>

clone <repository-url> --branch <branch-name>

Clone a repository and checkout the specific branch. 

git clone <repository-url> --branch <branch-name>

clone <repository-url> --depth <depth>

Clone a repository with a specified number of commits (<depth>). 

git clone <repository-url> --depth <depth>

clone <repository-url> --no-tags

Clone a repository without copying the repo’s tags.

git clone <repository-url> --no-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

config --global user.email "email@address"

Sets the email address associated with your Git commits and other Git actions.

git config --global user.email "my@mail.address"

config --global user.name "name"

Sets the user name associated with your Git commits and other Git actions.

git config --global user.name "My Name"

config --global core.editor "editor"

Sets the text editor Git should use when creating commit messages. Replace editor with your preferred text editor, for example vim, nano or subl for Sublime Text. On Windows, set the path to your preferred editor like C:/Program Files (x86)/Notepad/notepad.exe.

git config --global core.editor "vim"

config --list

Lists all the Git configuration settings currently set on your system.

git config --list

config --local --edit

Opens the Git configuration file from the current repo (.git/config) in the default text editor, allowing you to manually edit the settings.

git config --local --edit

config --global --edit

Opens your personal Git configuration file (~/.gitconfig) from the home directory in the default text editor, allowing you to manually edit the settings.

git config --global --edit

config --system --edit

Opens the Git application configuration file (<Git folder>/etc/gitconfig) in the default text editor, allowing you to manually edit the settings.

git config --system --edit

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

merge

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.

git merge

merge <branch-name>

Merge changes from one branch into the branch you currently have checked out.

git merge develop

merge --abort

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.

git merge --abort

merge --continue

Attempt to complete a merge that was stopped due to file conflicts after resolving the merge conflict.

git merge --continue

merge --squash

Combine all changes from the branch being merged into a single commit rather than preserving them as individual commits.

git merge --squash

merge --no-commit

Combine branch into the current branch, but do not make a new commit.

git merge --no-commit develop

merge --no-ff

Creates a merge commit instead of attempting a fast-forward.

git merge --no-ff develop

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

pull

This command fetches, and merges changes from the remote repository into your current local branch.

git pull

pull --quiet

Suppress the output text after both git fetch and git merge.

git pull --quiet

pull --verbose

Expand the output text after both git fetch and git merge.

git pull --verbose

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

--force overwrites the remote branch with your version, no questions asked. If a colleague pushed something in the meantime, their commits are gone.

--force-with-lease does the same job, but first checks that nobody else has pushed since you last fetched. If somebody has, the push is refused and nothing is lost:

git push --force-with-lease origin main

Never force push to a shared branch such as main unless everybody working on it knows about it.

Command Description Example

push

Push the current checked out branch to the default remote origin. 

git push

push <remote> <branch>

Push the specified local branch along with all of its necessary commits to your destination remote repository. 

git push origin main

push <remote> --force

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.

git push <remote> --force

push <remote> --all

Push all local branches to a specified remote.

git push <remote> --all

push <remote> --tags

Push all local tags to a specified remote (<remote> can be left out for the default remote). Note that tags are not sent automatically when using --all.

git push origin --tags

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 rebase is a flexible way to manipulate the commit history. Still, it’s important to use it cautiously, especially when working on shared branches (like the main branch), as it rewrites the commit history and can cause problems for other collaborators.

Here are some commonly used Git rebase commands:

Command Description Example

rebase <target branch name>

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.

git rebase <target branch name>

rebase --continue

Proceed with a Git rebase after you have resolved a conflict between files.

git rebase --continue

rebase --skip

Skip an action that results in a conflict to proceed with a Git rebase.

git rebase --skip

rebase --abort

Cancel a Git rebase. Your branch will be back in the state it was before you started the rebase.

git rebase --abort

rebase <target branch name> -i

Initiate interactive rebase from your currently checked out branch onto a target branch.

git rebase <target branch name> -i

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

stash

Create a stash with local modifications and revert back to the head commit.

git stash

stash list

Display a list of all stashes in your repository.

git stash list

stash show

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.

git stash show

stash drop <stash>

Remove a stash from the list of stashes in your repository.

git stash drop <stash>

stash pop <stash>

Apply a stash to the top of the current working tree and remove it from your list of stashes.

git stash pop <stash>

stash apply <stash>

Apply a stash on top of the current working tree. The stash will not be removed from your list of stashes.

git stash apply <stash>

stash clear

Remove all stashes from your repository.

git stash clear

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 --hard also throws away changes in your working folder that are not committed yet, and those changes cannot be brought back. Commit them or put them aside with git stash first if you may still need them.

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 217a618

Update 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 main

Push 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 main

Removing 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 -n

You 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 -df

Also removing ignored files:

git clean -dfx

Tag 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

from local
git tag -d v2023.4.2
from remote
git push -d origin v2023.4.2

Set 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 --tags

Index 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-files

Lists all of the already committed files being tracked by the repo:

git ls-tree --full-tree -r --name-only HEAD