Technical education fails quietly. A command that no longer behaves as documented does not announce itself — the reader runs it, gets something unexpected, and concludes they misunderstood.
This page describes how Modern Git Academy tries to avoid that, and what its accuracy claims are actually worth.
The standard every lesson is held to
Section titled “The standard every lesson is held to”Every published command has been run. Output shown in a lesson is real output from running it, not output reconstructed from memory or inferred from documentation.
That single rule drives most of what follows. It is also the rule most likely to be quietly broken by a writer working at speed, which is why the rest of this page exists.
How content is researched
Section titled “How content is researched”Primary sources first. Behaviour is checked against git-scm.com documentation, the Git manual
pages installed on the machine being used, and docs.github.com for the platform’s own features.
Secondary sources — blog posts, answers on forums, other tutorials — are not treated as authority.
Manual pages beat remembered behaviour. Git’s documentation is precise about edge cases in a way
that recollection is not. Where a lesson makes a claim about what a flag does, that claim is checked
against git help <command> for the version being documented.
Platform features are checked at the time of writing. GitHub’s feature set moves. A capability that was in public preview last quarter may be generally available now, restricted to certain plans, or renamed. Nothing about a platform feature is written from memory.
Version and plan differences are stated, not smoothed over. Where behaviour differs between Git versions, between GitHub plans, or between GitHub.com and GitHub Enterprise Server, the lesson says so rather than describing one case as universal.
How commands are tested
Section titled “How commands are tested”Run in a disposable repository. Commands are executed in a throwaway repository created for the purpose, so the starting state is known and nothing depends on an unstated local configuration.
Output is pasted, not paraphrased. When a lesson shows terminal output, that text was produced by running the command. Where output is trimmed for length, it is trimmed — not edited.
Destructive commands are tested including their failure modes. A lesson that shows how to recover from a mistake has had that mistake made deliberately, and the recovery verified.
Environment is recorded where it matters. Version-sensitive lessons carry a note recording what they were verified against, so a reader can tell whether a lesson predates a change.
How code examples are validated
Section titled “How code examples are validated”Workflow and configuration files are checked mechanically. Repository tooling validates YAML workflow examples and flags references to action versions that have fallen behind the versions the site claims to document.
Examples are minimal but complete. An example is cut down to what demonstrates the point, then checked that it still works after cutting. A snippet that only works with omitted context is a defect.
Placeholders are obviously placeholders. Organisation names, repository names, tokens and identifiers in examples use forms that cannot be mistaken for real values. No example ever contains a real credential.
How screenshots and interface descriptions are handled
Section titled “How screenshots and interface descriptions are handled”Interface descriptions are preferred over screenshots. Vendor interfaces are redesigned frequently, and a screenshot ages badly and invisibly. Where a lesson needs to describe a setting, it names the setting and its location in words, which survives a visual redesign.
Where an interface description is load-bearing, it is dated. Version-sensitive lessons record what they were checked against.
How outdated information is found
Section titled “How outdated information is found”Version-sensitive lessons are marked. Content that depends on a specific tool version, platform behaviour or vendor interface carries metadata identifying it as such, which makes the set of pages needing periodic re-checking a query rather than a memory exercise.
Tooling flags drift it can detect. Automated checks catch broken internal links, malformed metadata and stale action version references on every build. These catch mechanical rot, not conceptual rot.
Conceptual rot needs a human. A lesson can be entirely valid mechanically and still describe a practice the ecosystem has moved past. That is found by re-reading, and by readers reporting it.
How corrections are handled
Section titled “How corrections are handled”Corrections are welcome and are treated as the most valuable feedback the site receives. The corrections policy sets out what to report, what makes a report actionable, and how different classes of error are prioritised.
Technical errors take priority over everything else, including new content. A lesson that teaches something incorrect is worse than a lesson that does not exist.
Where AI assistance fits
Section titled “Where AI assistance fits”Some drafting and research on this site is AI-assisted. That is stated plainly because the alternative — letting readers assume otherwise — is not honest.
What that does not mean:
No command is published because a model produced it. Model output is a draft. Every command in a published lesson was run by a human in a real repository, and the output shown is what that run produced. A model’s recollection of a flag’s behaviour is treated exactly like any other unverified secondary source: as a lead to check, not a fact to publish.
No factual claim is published on a model’s authority. Version numbers, limits, plan availability and feature behaviour are checked against primary documentation regardless of where the draft sentence came from.
Structure and prose get human editorial judgement. What a lesson should cover, what to leave out, what the reader’s actual difficulty is — these are editorial decisions, and they are made by a person.
This is the same standard the site applies to its own content about AI tooling: deterministic steps decide, AI steps inform.
Accuracy over volume
Section titled “Accuracy over volume”The site publishes complete pages or nothing. There are no stub pages, no “coming soon” placeholders and no thin pages created to occupy a URL. An area that has not been written simply has no pages in it.
This is a deliberate trade. It means the curriculum grows more slowly than it could, and it means a page that exists can be relied on.
Who is responsible
Section titled “Who is responsible”Content is published under the site’s name and the editorial standard described on this page. Where an individual editor is named above, that person is accountable for it.