The Cheatsheet discuss 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.
Git 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:
-
Untracked files: Untracked files are displayed in red color by default. These are files that Git is not currently tracking.
-
Modified files: Modified files are displayed in green color by default. These files have been modified but still need to be staged for commit.
-
Staged files: Staged files, ready to be committed, are usually displayed in a different color from modified files. By default, staged files are not assigned a specific color, but they appear in a separate section from modified files.
-
Renamed or moved files: Renamed or moved files are displayed in green, indicating that they have been renamed or moved since the last commit.
-
Deleted files: Deleted files are displayed in red, indicating that they have been removed from the repository.
-
Unmerged files: Unmerged files, resulting from conflicts during a merge operation, are typically displayed in a different color, such as yellow or purple.
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"]
ignored = grey
added = yellow
changed = green
deleted = red
new = orange
untracked = magenta
Color | Description |
---|---|
| Ignored file or folder by |
| New file or folder. |
| Modified file or folder. |
| Deleted file or folder. |
| Untracked file or folder (may NOT used by Atom). |
Git 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
co = commit -am
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
rm = rm -r --cached .
rf = rm -rf --cached .
st = status
ty = 'cat-file'
Branch Commands
Git is a distributed version control system that allows you to manage multiple code branches within a repository. A branch in 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 it to the main branch for a new stable version.
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. |
|
Checkout Commands
The git checkout
command is used to switch between branches, create new branches, or restore files to a previous state.
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 |
|
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. |
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.
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. |
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.
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. |
|
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 it’s been cherry picked, you can either continue working with the changes before committing, or you can immediately commit the changes onto the target branch. |
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.
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:
-
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
-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 |
---|---|---|
| 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. | Commit all files iin the current folder indicazed 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 |
|
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 [editor] with your preferred text editor (e.g., "vim," "nano," "subl" for Sublime Text). On Windows, set the path to your preferred editor like |
|
| Lists all the Git configuration settings currently set on your system. |
|
| Opens the Git configuration file fron 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).
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 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. |
|
These are the basic commands for merging branches in Git. Additionally, you can use some more options and flags with these commands to modify their behavior. I recommend consulting the Git documentation for a more comprehensive understanding of the available options and scenarios where merging can be used effectively. |
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
– Combine the currently checked out branch with the remote upstream branch. -
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:
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 loose commits, so use with care. |
|
| Push all local branches to a specified remote. |
|
| Push all local tags to a specified remote (can ommitted for default remote). Note that tags are not automatically sent when using |
|
Rebase Commands
The git rebase
command that integrates changes from one branch onto another. It allows you to modify the commit history of a branch by moving, combining, or deleting commits.
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. |
|
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 rewrite the commit history and potentially cause issues for other collaborators. |
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.
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. |
|
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. |
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 .
.
git rm -r --cached . && git add .
or forced
git rm -rf --cached . && git add .
Commit commands
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. |
|
Create a new repository on the command line
echo "# Heroku starter_app" >> README.md
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 are on Windows. This may helpful when shell scripts are created and execute rights are required 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. |