arslanbilal/git-cheat-sheet: one page for the git commands you actually type

How the sheet is organised

The repository is five files and one of them matters. The tree holds `.gitignore`, a `README.md`, an `Img/` folder for the git logo, `_config.yml` for a Jekyll site, a `.travis.yml` from an earlier era, and an `other-sheets/` directory. There is no package manifest, no build system and no test suite, which is the correct shape for a document like this.

The README carries a table of contents with twelve sections: setup, configuration files, create repository, local changes, search, commit history, move and rename, branches and tags, update and publish, merge and rebase, undo, and git flow, followed by an other-languages entry. That grouping is the main editorial decision in the whole project. Commands are ordered by what you are trying to do rather than alphabetically, so a reader who wants to stage part of a file finds it in the same screen as the commands that commit it.

Every entry follows the same two-part shape: a bold line describing the intent, then a fenced block holding the command. That consistency is what makes the document scannable, and it is also why the repository can be translated mechanically without restructuring.

Contributions are invited in three specific forms: fixing grammar, adding commands, and translating to another language. With 7,459 stars and 1,443 forks, it is one of the most forked documentation repositories on GitHub, and the small open issue count of two suggests the content has settled.

Configuration scopes and the files behind them

The setup section opens with four near-identical commands, and their only difference is the scope flag, which makes them a good teaching example of how git resolves configuration:

git config --list
git config --local --list
git config --global --list
git config --system --list

A small table under them names the file each scope reads: repository settings in `<repo>/.git/config` for `--local`, user settings in `~/.gitconfig` for `--global`, and system settings in `/etc/gitconfig` for `--system`. Once you know those three paths, the recurring surprise where a setting appears not to apply is usually explained by a value set at a wider scope than you expected.

The user configuration entries set `user.name` and `user.email` globally, then cover display and editor behaviour with `color.ui auto` and `core.editor vi`. Those are the two settings that most often differ between a developer's machines, and having them side by side with the scope table is the reason this section is the most useful part of the document.

The same logic continues into the create-repository section, which shows cloning over SSH and over HTTPS with `git clone`, then `git init` both in the current directory and in a named one. Nothing here is novel, which is the point: these are commands that work identically on every machine and every operating system.

Staging, committing and where the sheet warns you

The local changes section runs from `git status` and `git diff` through staging, committing, amending and stashing, and it is the longest part of the README. Staging is where most beginners lose time, so it gets three entries: add everything with `git add .`, add named files, and add hunks interactively with `git add -p <file>`.

Committing has five, including the two that get confused most often. `git commit` commits what is staged, while `git commit -a` commits tracked files without staging first. The sheet also includes a backdated commit that shells out to `date`, which is a small piece of pragmatism that belongs on a reference page.

git commit --date="`date --date='n day ago'`" -am "<Commit Message Here>"

Then the warnings. Amending published commits carries an explicit warning in the sheet, which is the correct instinct and the most commonly ignored rule in git. The amend entries distinguish changing the message with `--no-edit`, moving the committer date through the `GIT_COMMITTER_DATE` environment variable, and moving the author date with `--date`, a distinction that matters when you are reconstructing history forensically.

The stash block is where the sheet is most opinionated, and rightly so. It includes the three-step dance for moving uncommitted changes onto another branch: stash, check out the other branch, then pop. That pattern is genuinely useful and genuinely not obvious.

Searching history when you do not remember the commit

The search and commit history sections are the parts of the sheet that go beyond a command list, because they answer questions rather than fill a template slot. Text search is `git grep`, which can be scoped to a ref such as `git grep "Hello" v2.5`.

Commit search is the interesting one. `git log -S 'keyword'` finds the commits that changed the number of occurrences of a string, which is how you locate the commit that introduced or removed a line without knowing its message. Adding `--pickaxe-regex` treats the string as a regular expression instead of a literal.

git log -S 'keyword'
git log -S 'keyword' --pickaxe-regex

The commit history section covers the expected basics like `git log`, `git log --oneline` and `git log -p <file>`, then moves into the less obvious. `git log --oneline <origin/master>..<remote/master> --left-right` compares two remote-tracking branches and labels which side each commit is on, which is a faster answer to the question than a full diff. `git blame <file>` is described as showing who changed what and when.

Reference logs get their own pair of entries, `git reflog show` and `git reflog delete`. Including `reflog` at all is a mark of quality, because it is the record that turns most of the undo section from a warning into a recoverable operation.

Branches, tags and the publishing section

Branch coverage is thorough and includes the operations people hesitate to run. Listing comes in five variants: local, all, remote, and merged. Creating and switching covers the ordinary cases plus three that are easy to forget, namely creating without switching with `git branch <new-branch>`, creating a tracking branch with `git branch --track`, and creating from a specific commit.

Deleting is split the way git itself is, between `git branch -d` for a safe delete and `git branch -D` for the forced one, and the forced version carries a warning in the sheet that you will lose unmerged changes. Cherry-picking a single commit from another branch is also included, which makes this section cover the branch-level operations rather than stopping at the basics.

Tags are handled with the same attention to the distinction between forms: a plain `git tag <tag-name>` at HEAD, an annotated `git tag -a`, a tagged tag with a message using `-am`, and the two listing forms with and without messages.

The update and publish section opens with remote management, `git remote -v` for listing configured remotes. That section leads into the merge and rebase entries in the table of contents, which are where a cheat sheet starts making real editorial choices, since the merge-versus-rebase question is the one place where copying a command without reading the context causes damage.

Git Flow, translations and what the repository does not track

The table of contents ends with git flow and other languages, which tells you two things about where this project sits. Git flow is the most opinionated branching model in common use, with named long-lived branches and a release cadence attached to branch names, and including it in a general cheat sheet is a choice rather than an obligation. Everywhere else the document stays descriptive, listing commands and their effects, so the git flow section is the one place where the author is prescribing a workflow.

The other-languages entry and the `other-sheets/` directory are the most distinctive thing about the repository. Translations are maintained as separate files rather than as a plugin or a crowdsourced wiki, which means a translator can work without touching the English original and the maintainer can merge translations without reviewing English text. The topics listed on the repository are cheatsheet, git, git-flow and github, which is an accurate four-word description of the whole project.

What the repository does not do is track git itself. There is no version file, no releases page, and no changelog, so there is no way to tell from the repository which git version the commands were written against. The commands shown are the long-standing porcelain rather than the newer `git switch` and `git restore` forms, which is a deliberate-looking choice on a document people read to be conservative. The last push was on 2026-03-04, so treat it as a well-settled document rather than one that follows each git release.

Editorial conclusion

What this repository does is unglamorous and useful: it puts the git command you are trying to remember next to a one-line description of what it does, grouped by the task rather than by subcommand. The configuration scope table, the warnings attached to amend and force-delete, and the pickaxe and reflog entries are the parts worth reading even if you know most of it already. Two things are worth knowing before you rely on it. The commands shown are the established porcelain, not the rewritten `git switch` and `git restore` vocabulary, so treat it as a record of how git has long been used rather than a recommendation about current style. And the last push was on 2026-03-04, which means this is a maintained-by-accumulation document rather than one being kept in step with every git release. Start at the configuration files table if git config has ever surprised you, then read the Local Changes and Commit History sections, which is where the sheet has the most commands per screen.

Frequently asked questions

Official sources

1. arslanbilal/git-cheat-sheet on GitHub
2. Issues
3. README