# The GitHub Cheat Sheet documents URL tricks GitHub never published > The GitHub Cheat Sheet is a Markdown list of hidden Git and GitHub behaviours, translated into five languages and licensed MIT. Its most useful entries are undocumented query strings appended to GitHub URLs, which is what makes it worth reading and also what makes it fragile: the last push was on 2024-04-15 and there are no releases. **tiimgreen/github-cheat-sheet** — A list of cool features of Git and GitHub. - Repository: https://github.com/tiimgreen/github-cheat-sheet - Website: http://git.io/sheet - Stars: 59,355 · Forks: 5,457 - Language: Unknown - License: MIT - Published: 2026-08-17 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/tiimgreen-github-cheat-sheet ## The core entries are URL parameters GitHub never published Most of the sheet's value sits in query strings appended to a GitHub address, and none of them are documented by GitHub. Adding `?w=1` to any diff URL removes changes that are only whitespace, so a reformat stops looking like an edit. Adding `?ts=4` to a diff or file URL draws tab characters four spaces wide instead of the default eight, and the number after ts can be whatever you prefer. Adding `?author={user}` to a commits address narrows the history to one person, which the sheet shows against a real repository. ``` https://github.com/rails/rails/commits/master?author=dhh ``` That is the whole mechanism, and it is also the whole risk. An undocumented parameter carries no compatibility promise, so GitHub can change its behaviour or remove it, and the only evidence in this repository that an entry still works is a commit. The most recent one is dated 2024-04-15. ## The tab width parameter skips Gists and raw views One of the three carries its own documented failure, and the sheet is direct about it. The `?ts=4` trick does not work on Gists or on raw file views, and the offered remedy is a Chrome extension that automates the parameter for you. That is a fair trade for someone reading diffs in a browser all day, and a poor one for anyone who has to install browser software to see indentation correctly, or who needs the same rendering in a terminal, in a script, or during a code review on a machine they do not control. The asymmetry is the point. `?w=1` and `?author=` are pure query strings with nothing to install, so a failure there costs one click. The tab width trick has a fallback that adds a dependency with its own update cycle, and the sheet says nothing about what a page looks like when the extension is absent, which is the state of anyone reading on a locked-down or shared machine. ## Branch comparison is a URL grammar with no command behind it The compare section teaches a small language rather than a single command. The address takes the shape `https://github.com/{user}/{repo}/compare/{range}`, and `{range}` is the interesting half, because its left side accepts a revision expression and not only a branch name. ``` https://github.com/rails/rails/compare/master@{1.day.ago}...master https://github.com/rails/rails/compare/master@{2014-10-04}...master ``` Dates inside that syntax are written `YYYY-MM-DD`, and appending `.diff` or `.patch` to the same address returns the raw form instead of the rendered one. The strength is being able to ask a question about a range that log flags do not answer as directly. The weakness is that this is a grammar with no published specification, and the Git half of the sheet offers no command line equivalent, so anything you want to repeat at scale has to be built by hand from the URL pattern. ## URL tricks sit next to commands that will outlive the interface The table of contents splits in two and the halves age at different speeds. The GitHub half is a list of surfaces: Quick Quoting, Task Lists, Rendering Tabular Data, Rendering PDF, Quick Licensing, Metadata and Plugin Support for GitHub Pages, Diffable Maps, and then a tail of entries such as Hub, GitHub Talks, the Student Developer Pack, SSH keys and Repository Templates. The Git half is a list of commands: Stripspace, Previous Branch, Empty Commits, Git Grep, Fixup and Autosquash, a styled Git log, and configuration groups for aliases, auto-correct and colour. A command that shells out to git keeps working when the interface around it is redesigned, and most of those will. A named GitHub surface changes when the product changes, and nothing marks which kind of entry you are reading until you open the section. Treat the sheet as one flat list of tips and you will assume they are equally durable. They are not. ## Five README files and no stated way to keep them together The repository root holds five copies of the sheet: README.md in English, README.ko.md, README.ja.md, README.zh-cn.md and README.zh-tw.md. That is real value for a reader who does not read English, and it is also the document's largest internal maintenance surface, because each of those is a full copy rather than an import. A translated copy drifts in a way an English one cannot. A tip that names an English interface element becomes two fragile references at once, since the element can be renamed in the product and the translation can lag the original sentence. The root listing also carries a CONTRIBUTING.md, so there is a place where a process could be described, but nothing in the visible text says how the translations are synchronised, who signs them off, or what a translator should do when a section disappears from README.md. Anyone relying on the Korean or Chinese copies is reading a document whose sync policy is unwritten. ## Cloning is the only install step, and the shortlink is a redirect There is nothing to build and nothing to run. The sheet is Markdown, and the one command it gives for obtaining it leaves the `.git` suffix off the end of the clone address, which git accepts. ```bash $ git clone https://github.com/tiimgreen/github-cheat-sheet ``` The memorable address is a different one. The project offers http://git.io/sheet as a shortlink, so the URL a reader is likely to keep is a redirect standing in front of the real file rather than the file itself. A redirect is one more thing that can stop resolving, and the sheet offers no second shortlink and no note about what to do if it does. The repository root is the address that does not depend on anyone else's infrastructure: nine entries, five of them the same document in different languages, plus a licence file, a CONTRIBUTING.md and a `.travis.yml`, which raises a fair question the sheet never answers about what that CI job checked in a repository with no code in it. ## Last push 2024-04-15, no releases, no changelog Maintenance is where this repository is thinnest, and the facts are short. It is not archived, the last push was on 2024-04-15, and it publishes no GitHub releases, so there is no tag, no version and no release note to check an entry against. The default branch is master, and the project ships under the MIT licence with the licence file in the root. The consequence for a team is specific. You cannot say which entries were verified against which version of GitHub, because the document records that nowhere, and you get no upgrade signal when GitHub changes something, because there is nothing published to watch beyond the commit list. A sheet built on undocumented URL parameters is the kind of document that ages quietly, which is what makes the licence the practical mitigation. MIT lets you copy README.md into an internal repository, add the date you checked each entry, and own the maintenance from there. Forking is the only upgrade path on offer, and it is a permissive one. ## Conclusion This sheet suits a developer who wants a short list of GitHub behaviours to try and who will verify each one, because every entry is a starting point rather than a guarantee. It does not suit a team that needs a reference carrying a support commitment, since the last push was on 2024-04-15, there are no releases, and no entry says which version of GitHub it was written against. Use it as a list of things to try, then keep your own copy: the MIT licence lets you fork README.md into an internal document, and a document you own is the only version of this one that will carry a date. ## FAQ ### Where can I find a Git cheat sheet? The full text sits in README.md at the repository, reachable through the shortlink http://git.io/sheet, with Korean, Japanese, Simplified Chinese and Traditional Chinese versions as separate README files in the same root directory. ### Is the tiimgreen GitHub Cheat Sheet still current? The last push was on 2024-04-15 and the repository publishes no GitHub releases, so there is no version an entry can be checked against. Many of the tips are undocumented GitHub URL parameters, which the project does not track against changes in GitHub itself. ### Which GitHub URL parameters does the cheat sheet rely on? Adding ?w=1 to a diff URL hides whitespace-only changes, ?ts=4 changes tab width from the default 8 to 4, and ?author={user} filters a commit history to one author. The tab width parameter does not work on Gists or raw file views. ### What licence is the GitHub Cheat Sheet under? MIT, with the licence file in the repository root. Contributions are handled through the CONTRIBUTING.md in the same root, alongside five translated copies of the sheet. ## Sources - [Official documentation](http://git.io/sheet) - [Official README](https://github.com/tiimgreen/github-cheat-sheet#readme) - [Project repository](https://github.com/tiimgreen/github-cheat-sheet) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tiimgreen-github-cheat-sheet