# git/git-scm.com: the repository behind the Git homepage

> This is the source for git-scm.com, the Hugo site that serves as the landing page for Git itself. It is a website repository, not Git, and it is built and deployed in ways that shape who can contribute.

**git/git-scm.com** — The git-scm.com website. Note that this repository is only for the website; issues with git itself should go to https://git-scm.com/community.

- Repository: https://github.com/git/git-scm.com
- Website: https://git-scm.com/
- Stars: 2,416 · Forks: 1,441
- Language: HTML
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/git-git-scm-com

## A website repository that happens to carry the Git name

git/git-scm.com is not Git. It is the source of git-scm.com, the site the README describes as the first place a person new to Git will land to download or learn about the Git SCM system. The distinction matters because the repository's issue tracker and pull requests are about pages, layouts and data files, not about the version control tool. If your problem is a Git bug, a Git command behaving unexpectedly or a Git release, this repository is the wrong place, and the README points elsewhere: issues with Git itself should go to https://git-scm.com/community.

The audience is therefore narrow but real. People who maintain the GUI listing in data/, people who touch layouts and content, and people who work on the scheduled pre-rendering of the ProGit book and the manual pages all have business here. The repository is HTML-heavy by primary language, with Hugo templates and data files doing the structural work. The MIT licence covers the site code; the pre-rendered book and manual pages come from other repositories and are pulled in by workflows, so editing external/book/ or external/docs/ by hand is explicitly discouraged.

## Hugo, GitHub Pages and the ugly URL decision

The site is built with Hugo and served through GitHub Pages. That pairing explains most of the oddities in the README. Hugo by default writes pretty URLs such as https://git-scm.com/about/ with a trailing slash; GitHub Pages instead resolves an even shorter URL like https://git-scm.com/about by appending .html. To match production, this project wants Hugo's ugly URLs, so the local workflow has to turn the default off.

The repository has a helper for this. node script/serve-public.js emulates GitHub Pages behaviour, while hugo serve does not, which is why the README recommends the Node script for ordinary local viewing. The same quirk produces the Windows warning: some URLs contain question marks for historical reasons, encoded as %3F in the URL but literal question marks in Hugo's output filenames. Linux filesystems accept those names; Windows forbids them. The README offers a workaround that rewrites the url front matter of affected files, and is honest that the result loses the backwards-compatible URLs containing URL-encoded question marks. That is a genuine trade-off, not a footnote.

Content that is not authored here arrives through scheduled pre-rendering workflows in .github/. The external/book/ and external/docs/ directories hold the ProGit book, its translations, the manual pages and their translations. The script/ directory holds the code that produces them. If you edit those outputs directly, the next scheduled run is likely to overwrite your work.

## Installing Hugo and serving git-scm.com on port 5000

The README recommends cloning with scalar so that only the directories you care about are checked out, then narrowing further with sparse-checkout. A manual sparse, partial clone is given as the fallback when your Git installation has no scalar.

```console
$ git clone --filter=blob:none --no-checkout https://github.com/git/git-scm.com
$ cd git-scm.com
$ git sparse-checkout set layouts content static assets hugo.yml data script
$ git reset --hard
```

After that, rendering locally requires Hugo's extended version v0.128.0 or later. The README gives a command to verify it, and the expected output names the extended build.

```console
$ hugo version
hugo v0.128.0+extended linux/amd64 BuildDate=unknown
```

With Hugo in place, the site is served through the Node script, and the README states it should be running on http://127.0.0.1:5000.

```console
$ node script/serve-public.js
```

If you prefer Hugo's own server, you must disable ugly URLs, which moves the address to http://127.0.0.1:1313.

```console
$ HUGO_UGLYURLS=false hugo serve -w
```

Search is a separate step. Pagefind indexes the generated public/ directory, and the README warns that this makes the process about 7 times slower and stops live reloading from working when files under content/ change. To pin the same Pagefind version used in deployment, the version is read out of hugo.yml.

```console
$ hugo
$ npx -y pagefind --site public
$ node script/serve-public.js
```

## The Playwright suite and the sparse checkout it forces

The site has its own test suite. It uses Playwright, the tests live in tests/, and the configuration is playwright.config.js. The README describes them as a couple of tests that verify that the site looks right, and warns that building the site, generating the Pagefind index and then running the suite can be time consuming.

The recommended mitigation is a deliberately odd sparse checkout. It disables the cone mode, enables sparse checkout for the worktree, and then lists individual files rather than directories, down to single book chapters such as the Azerbaijani getting-started page and the English page about version control. That is a useful signal about how the tests work: they exercise a small, fixed set of pages, so a contributor does not need the whole content tree to run them.

This is also the clearest limitation of the repository for casual contributors. If you only want to fix a typo on one page, the full local pipeline is heavier than the edit. The README itself recommends sparse checkouts repeatedly, which is an admission that the default full clone is uncomfortable. Whether that matters depends on your goal: a one-line content change can plausibly go straight to a pull request, while layout or search changes really do need the local build.

## Why git-scm.com is not the same as GitHub

A recurring confusion is whether git-scm.com is GitHub, or whether Git SCM and GitHub are the same thing. They are not. Git is the version control system; git-scm.com is its website, and this repository is the source of that website. GitHub is a hosting service that the site happens to use for deployment through GitHub Pages, which is why the default branch here is gh-pages rather than main.

That deployment choice has consequences for anyone reviewing a change. The published site is the output of a Hugo build pushed to a branch, not a server-rendered application. There is no application runtime to debug on the host, and the search index is a static artefact generated by Pagefind at build time. If a search result is wrong, the fix is in the indexing step or the content, not in a running service.

The comparison that matters for contributors is with editing the rendered site. You cannot. The pre-rendered ProGit book, its translations, the manual pages and their translations are produced by GitHub workflows that source content from other repositories. The README is explicit that you should avoid editing external/book/ and external/docs/ directly. For translated manual pages or book chapters, the correct place to change text is the upstream repository that the workflow pulls from, which makes this site a consumer rather than the owner of that content.

## Windows, question marks and the build that will not run

The sharpest failure mode in the README concerns Windows. If you cannot use Windows Subsystem for Linux, the README states plainly that you will be unable to build the site as-is. The cause is not Hugo itself but the historical URLs containing question marks, which become literal question marks in output filenames, and Windows forbids those characters. Colons in some filenames cause a similar checkout problem, which is why WSL is recommended even for cloning.

The documented workaround rewrites the url front matter of the affected files, strips the question marks, and marks the files assume-unchanged in the index. The README then states the cost directly: the result does not support the backwards-compatible URLs that contain URL-encoded question marks. So the workaround buys a local build at the price of no longer reproducing those URLs. If your change concerns routing or redirects, that is exactly the wrong environment to test in.

This is the case where the repository is the wrong tool. If your only machine is Windows without WSL, and your task depends on URL behaviour, contributing here means either setting up WSL or accepting that your local build diverges from production. Neither is hidden by the README, which is to its credit, but both are easy to miss if you skim.

## Maintenance, licence and what to verify before contributing

The repository is not archived, and the last push was on 2026-09-23, so work is landing. Release notes are not part of this project's workflow in the way they are for a library: package.json declares version 0.0.0 and lists only devDependencies, namely @playwright/test, @types/node and node-html-parser. There is no published package to upgrade, so upgrade cost is about toolchain versions rather than dependency bumps.

The versions that actually matter are documented in the README and in hugo.yml: Hugo extended v0.128.0 or later, and a Pagefind version read out of hugo.yml so that local search matches deployment. Node is required for script/serve-public.js and for npx pagefind. There is also a .ruby-version file and a Gemfile at the top level, which suggests a Ruby toolchain is part of some workflows, though the README does not describe it.

On licensing, the repository carries MIT-LICENSE.txt and package.json declares MIT. The MIT terms cover the site code in this repository. The pre-rendered book and manual pages originate from other repositories under their own terms, and the README's instruction not to edit them directly is also the practical boundary of what this licence covers. That is a description of the repository layout, not legal advice; if you plan to reuse the book or manual content, check the upstream sources.

Before opening a pull request, verify three things: that hugo version reports the extended build at v0.128.0 or later, that your sparse checkout includes the directories your change touches, and that you are not editing anything under external/. The README's directory list is the guide for the first two, and the third is stated outright.

## Conclusion

Adopt this repository if you are changing the git-scm.com site itself: page layouts, the GUI list in data/, or the scripts that pre-render the ProGit book and manual pages. Do not adopt it if you want to fix Git: the README says issues with Git itself belong at https://git-scm.com/community, and this repository is only for the website. Before your first commit, confirm your Hugo version is extended v0.128.0 or later with hugo version, and decide whether you need the sparse checkout, because a full clone plus Pagefind plus the Playwright suite is slow. If you work on Windows without WSL, the question mark URLs in content filenames will block the build until you run the README's sed loop.

## FAQ

### Is git-scm.com legit?

It is the official Git website; the README describes this repository as the source of git-scm.com and says the site is meant to be the first place a person new to Git will land. The repository is hosted under the git organisation on GitHub and carries an MIT licence.

### What is Git SCM used for?

Git is the version control system, and git-scm.com is its website, used to download or learn about Git. This repository is only the website source; the README directs issues with Git itself to https://git-scm.com/community.

### Is Git SCM the same as GitHub?

No. Git is the version control system and git-scm.com is its website, while GitHub is the hosting platform used here to serve the site through GitHub Pages. That is why the default branch of this repository is gh-pages.

### How do I install git-scm.com locally?

Clone the repository, ideally with scalar or as a sparse partial clone, then install Hugo's extended version v0.128.0 or later and serve the site with node script/serve-public.js on http://127.0.0.1:5000. Search requires an extra Pagefind step over the generated public/ directory.

### Can I build the git-scm.com site on Windows?

Not as-is without WSL. The README explains that some URLs contain question marks that become literal question marks in Hugo output filenames, which Windows forbids, and it gives a workaround that strips them at the cost of the backwards-compatible URLs.

### Is git-scm.com safe to download Git from?

The README describes this repository as the source of git-scm.com, the site meant to be the first place a person new to Git will land to download or learn about Git. The downloads pages are part of content/ here, while issues with Git itself are directed to https://git-scm.com/community.

## Sources

- [git/git-scm.com on GitHub](https://github.com/git/git-scm.com)
- [Issues](https://github.com/git/git-scm.com/issues)
- [License: MIT](https://github.com/git/git-scm.com/blob/gh-pages/LICENSE)
- [Project website](https://git-scm.com/)
- [README](https://github.com/git/git-scm.com/blob/gh-pages/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/git-git-scm-com