GitHub Training Kit: the courseware repo that is now only cheat sheets

What github/training-kit actually contains in 2026

The README is blunt about scope: "This repository currently contains Git and GitHub cheat sheets." Everything else that once lived here, including On-Demand training, reading lists, videos and book recommendations, was removed, and the README points to a specific commit in the repository history for anyone who wants the old material. So the thing you are evaluating is a static site of cheat sheets, not a course. The repository description still says "Open source courseware for Git and GitHub", and the topics list includes training and courseware, but the current tree is a Jekyll site plus a packaging script. The audience is narrow and practical: trainers, professional services engineers and internal developer enablement teams who want a set of Git and GitHub reference sheets they can hand out or serve from their own infrastructure. If you are looking for a self-paced Git course, this is the wrong repository, and the README says so in its own words.

How the Jekyll site and packaging script fit together

The build is conventional Jekyll. The top level holds _config.yml, _includes/, _layouts/ and _pages/, with assets/, downloads/, git-guides/ and index.html alongside them. Content is Markdown rendered through Jekyll, and the README names Jekyll and Markdown as the tools used, with Primer CSS for styling. The npm side is thin: package.json lists a single dependency, @primer/css, and its test script is the default placeholder that echoes an error and exits 1. There is no meaningful JavaScript test suite to run. The interesting piece is the packaging path rather than the build path. script/package produces a release tarball named release-XXXXXXX.tgz, which is the artifact you carry to an internal web server. Two redirect files sit at the top level, redirects.md and redirects-cheatsheets.md, which exist because cheat sheet URLs have moved over time. That is the part most people miss when they self-host: a plain static server will serve the files, but the README notes that some servers are more advanced than others when it comes to redirects and smart recognition of .html files.

Installing training-kit and serving it behind a firewall

The README gives an explicit sequence for producing and checking a local copy. First run the packaging script, which writes a tarball in the format release-XXXXXXX.tgz.

script/package

The README then suggests creating a directory layout and extracting the release into it. The three commands below are copied from that sequence; the tarball name will differ from release-XXXXXXX.tgz depending on what the script produced.

mkdir -p test_site/kit
tar -xzf release-XXXXXXX.tgz -C test_site/kit
cd test_site

From inside test_site you start a throwaway static server. The README lists both the Python 2 and Python 3 forms; use the one that matches your interpreter.

python -m SimpleHTTPServer
python -m http.server

What you should see is the extracted site served from the test_site directory, which is enough to confirm the tarball unpacked correctly before you move it to a real web server. The README adds a caveat worth reading twice: some servers handle redirects and extensionless .html paths better than others, so a passing check under python -m http.server does not guarantee the same behaviour on your production server.

Where training-kit stops being the right tool

The repository is not archived and the last push was on 2026-09-10, so the cheat sheets are being touched. That does not make it a maintained application. The latest release listed is 1.8.0 from 2015-01-08, and the packaging script and Jekyll layout are the same shape they have been for years. Two concrete limits follow. First, there is no curriculum: if your goal is to teach someone Git from zero, the sheets assume you already know what you are looking at. The README itself directs people who want the removed training material to an old commit, which is an archive, not a supported path. Second, the npm side gives you nothing to verify with. The test script prints an error and exits 1, so there is no automated check that the site renders correctly after your changes. If you fork the content and edit it, your only verification is loading the pages. Teams that need a tested, versioned documentation pipeline should look elsewhere rather than build one on top of this.

How this compares to writing your own Git reference

The obvious alternative is authoring your own internal Git and GitHub reference pages, which is what many platform teams end up doing. The difference in approach is maintenance ownership. With training-kit you inherit a set of cheat sheets that GitHub's Professional Services team wrote, and you take on the job of keeping your copy in sync with upstream if you want updates. With your own pages you control the exact commands and the exact GitHub UI wording, which matters because GitHub's interface changes and a stale screenshot or menu path in a cheat sheet is worse than no cheat sheet. The trade-off is real in both directions: upstream gives you coverage you did not have to write, and it gives you content that may describe an interface you no longer use. There is also a licensing difference to weigh. The content is CC-BY-4.0, so you must note the license and give credit, which the README shows as a specific attribution line. Your own pages carry no such obligation.

Licence terms and what they mean for internal use

The split is stated clearly in the README. Site content is under CC-BY-4.0, which permits use for almost any purpose as long as you note the license and give credit; the README supplies the attribution form: "Content based on github.github.com/training-kit/ used under the CC-BY-4.0 license." Code used to build and test the site, plus code samples on the site, are under CC0-1.0, which waives copyright restrictions. Neither licence grants trademark permissions, so GitHub marks stay off limits. The practical consequence for an internal deployment is that you should keep the attribution visible somewhere in the served copy, and you should not rebrand the sheets with your own logo in a way that implies the content is yours. Contributions to the repository are made under the same licences. This is a summary of what the README states, not legal advice; if the attribution requirement matters to your legal team, have them read the licence texts linked from the README.

Editorial conclusion

Adopt github/training-kit if you need Git and GitHub cheat sheets you can host inside your own network and you accept the CC-BY-4.0 credit requirement. Do not adopt it expecting a taught course: the README states the repository currently contains only Git and GitHub cheat sheets, and On-Demand training, reading lists, videos and book recommendations were moved out. Before you build anything on it, run script/package and confirm the tarball name and the extracted site under test_site/kit, then check that your own web server handles the redirect files (redirects.md and redirects-cheatsheets.md) the way the hosted site does.

Frequently asked questions

Official sources

1. github/training-kit on GitHub
2. License: CC-BY-4.0
3. Project website
4. README
5. Releases