git-flight-rules: an index written in panic, with a git 2.13.0 floor
Flight rules for git
At a glance
- What is it?
- A nine-language list of git recovery procedures, arranged by the mistake you just made instead of by command name, and borrowing its structure from NASA flight manuals as quoted by Chris Hadfield. It is a lookup table, not a tool, and its one version statement is a floor with no upper bound.
- Who is it for?
- Use it as a panic reference when you already know what went wrong and not which command fixes it, and reproduce its custom prompt first, because the staged-change marker is what makes half the rules safe to run. Do not use it as a curriculum, a review checklist, or a statement about current git behavior.
- Can I use it commercially?
- Yes, with credit. CC-BY-SA-4.0 allows commercial use as long as you credit the authors and indicate what you changed. It is written for creative content, so check how it applies to any code.
- Is it still maintained?
- Yes. The repository last received commits 69 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Every example runs under a custom prompt, because the rules depend on seeing staged changes
One convention is set before any command appears. All examples use a customized bash prompt so that the current branch and the presence of staged changes are both visible. The branch is enclosed in parentheses, and a `*` next to the branch name marks staged changes. That is a short sentence with a large consequence, because a large share of the entries turn on the difference between work that is in the index and work that is not. Rules about adding staged changes to the previous commit, or about staging part of a new file but not the whole file, are only safe to run if you can see which state you are in before you type. If you copy a command out of the page into your own shell, the signal that told the rule what state you were in is simply gone. Reproducing that prompt is the setup step this document never asks you to take, and it is the step that makes the rest of it readable.
The version floor is git 2.13.0, and nothing names an upper bound
A single line sets the target: all commands should work for at least git version 2.13.0, with a pointer to the git website to update your local version. That is the only version statement in the document, and it is phrased as a floor, so nothing anywhere establishes a ceiling or a tested range. Individual rules carry no dates either, which means you cannot tell which entries were checked against which git. The last push to the default branch `master` was 2026-07-23, but that tells you when the words changed, not which commands were verified against a given release. The effect is that a rule written for the 2.13 era gets handed to whatever git happens to be on your machine, and if the behavior has shifted since, the page does not warn you in advance. Run your most-used recovery command once against your own version before you need it under pressure.
History rewriting is a three-step job, and the secrets case gets the thinnest trail
Two entries deal with mistakes that no follow-up commit can undo. One covers accidentally committing and pushing files containing sensitive data. The other covers wanting to remove a large file from ever existing in repo history, and that one is broken into three named steps: a recommended technique that uses the third-party tool bfg, a built-in technique that uses git-filter-branch, and a final step of pushing your changed repo history. The order is the message. The rewrite is not a local operation, and a push step is part of the procedure rather than something you consider afterward. The asymmetry in the contents is worth noticing, because the large-file mistake gets its method spelled out as sub-entries while the sensitive-data mistake is a single line with nothing beneath it. For the mistake with the worst consequences, the entry you are sent to is the one with the least structure hanging off it.
Nine language files, and automation that only reaches the tables of contents
The repository holds the English README plus eight translations, among them Español, Русский, both Chinese variants, 한국어, Tiếng Việt, Français, and 日本語. `package.json` is marked private, so nothing is published anywhere, and it defines exactly two scripts.
"scripts": {
"toc": "doctoc --github README.md README_*.md",
"diff": "test -z \"`git diff -- README.md`\" && test -z \"`git diff -- README_*.md`\""
},The first regenerates the tables of contents with doctoc across every README at once, which is why each translation has a matching contents list even though a note in the page tells readers not to edit that section by hand. The second fails when the git diff of the README files is not empty. So the machine work covers the generated navigation and the state of your working tree. It does not cover parity between the nine documents: a rule corrected in English is corrected in English, and nothing in the repository compares the files against each other.
The headings are the mistake, not the command
Read the contents and the organizing principle is obvious. `I set the wrong remote repository`. `I accidentally did a hard reset, and I want my changes back`. `I committed to main instead of a new branch`. `What did I just commit?`. Not one of them names a git verb. The index is a lookup by symptom, written for the moment when you know what went wrong and do not know which command addresses it, which is a real advantage over a command reference when the clock is running. The cost shows up in the other direction. If you know the command you want and not the situation, this index will not get you there, because the verb only appears once you open the section. Search it the way it was built, from the failure, and keep your own short note mapping each failure you hit back to the command that fixed it.
Five entries for one verb, because discarding is a question of how much you lose
The Discarding changes section carries five separate entries: discarding all local uncommitted changes staged and unstaged, discarding specific unstaged changes, discarding specific unstaged files, discarding only unstaged local changes, and discarding all untracked files. Staging is treated with the same granularity, including an entry for staging part of a new file but not the whole file and another for choosing which entire files to stage. The overlap exists because the git commands in this family differ in blast radius, and the index pushes you to settle that question before you type anything. The risk comes from the same place. Two headings in one section can read as interchangeable, and choosing the wider one throws away work you meant to keep. The word naming the scope in the heading is the entire difference between the entries, so read that word rather than scanning for the verb.
Two lanes for the same contribution, and a hazard that only forks create
The Repositories section covers starting a local repository, cloning a remote one, adding code to someone else's repository, and keeping a fork current with the original. Adding code splits into two named lanes, suggesting code via pull requests and suggesting code via patches, and those two have different setup costs, since one assumes a fork you can push to and the other does not. That assumption also explains why the section carries a separate entry for setting the wrong remote repository, a mistake that exists only for people who cloned their own fork and are about to send work upstream. The fork lane is therefore three rules deep: keep the fork current, push to the right remote, open the request. Skipping the middle step is the case the section exists to catch, and it is the cheapest of the three to get wrong.
Editorial conclusion
Use it as a panic reference when you already know what went wrong and not which command fixes it, and reproduce its custom prompt first, because the staged-change marker is what makes half the rules safe to run. Do not use it as a curriculum, a review checklist, or a statement about current git behavior. Before trusting a procedure during an incident, check the command against the git version your team actually runs, and for anything involving pushed secrets, work out who else still holds a clone before you rewrite history.
Frequently asked questions
What are 12 common commands in Git?
The document does not count commands. It is organized as an index of situations, grouped into Repositories, Editing Commits, Staging, Discarding changes, and Branches, with entries phrased as the mistake you made rather than as the command to run, and its commands are written to work for at least git version 2.13.0.
What are the 5 steps of Git?
There is no numbered sequence here. The contents are grouped by problem area instead, with sections for Repositories, Editing Commits, Staging, Discarding changes, and Branches, and the order in which you need them depends entirely on which mistake you are trying to undo.
Is Git checkout obsolete?
The document does not discuss command deprecation or newer spellings. The only version statement it makes is a floor, that all commands should work for at least git version 2.13.0, and it points readers at the git website to update a local install.
What does Git push '-u do?
The contents carry no entry that sets out that flag. On the surrounding subject the index does include discarding local commits so your branch matches the one on a server, and a separate entry for the case where you pushed an amended commit to a remote and got an error message.