Degit: scaffolding from Git repositories without cloning history

The problem degit solves is the .git folder you did not ask for

When you start a project from a template, you usually want the files, not the template's history. A normal clone gives you both, so the first thing many people do is delete .git and re-initialize. Degit is built around that observation: run degit some-user/some-repo and you get the files of the latest commit on that repository, with no .git directory left behind.

The audience is narrow and identifiable. People who maintain starter templates, people who scaffold the same project shape several times a month, and people writing scripts that pull a known repository into a build directory. The README lists the reasons it gives for choosing it over git clone --depth 1: no leftover .git folder, cached tar archives that can be reused offline, less typing, post-clone actions through degit.json, and built-in support for subdirectories, file filtering and aliases.

That list is really a list of conveniences, and it is worth being honest about that. Degit is not a replacement for Git. It is a downloader with a small amount of scaffolding logic on top, and the moment you need to fetch updates, rebase, or push, you are back in Git.

How degit resolves a ref and downloads a tar snapshot

The README describes the flow directly. When you run degit some-user/some-repo, it finds the latest commit on https://github.com/some-user/some-repo and downloads the associated tar file into a platform-appropriate cache directory, unless that tar file is already cached locally. That cache is the reason a second run against the same ref can work without network access.

The README also states that degit resolves refs through an internal git backend, downloads tar snapshots by default, and falls back to SSH cloning when tarball fetches or extraction fail. That fallback is the part worth understanding before you put degit in a build script. Public HTTPS sources do not need a local git binary on your PATH, but SSH and private repositories still do. So a container image that runs degit against a public GitHub repository can be very small, while the same image pointed at a private repository needs git installed.

The repository layout supports the description: there is a src/ directory, a schemas/ directory (consistent with validating degit.json), a skills/ directory holding the agent skill, and a perf/ directory with a benchmark script referenced from package.json as bun perf/bench.ts. The package is ESM only, with "type": "module" and dist/index.js as the main entry, so consuming it as a library from CommonJS requires the usual interop handling.

Installing degit and scaffolding a first project

Degit requires Node.js 20 or later, as stated under Requirements in the README and in the engines field of package.json. Install it globally with npm:

npm install -g degit

With the binary on your PATH, the quick start downloads the default branch of a GitHub repository into the current directory:

degit user/repo

If the current directory is not empty, the README's guidance for agents is to avoid overwriting a non-empty destination without confirmation, so create the target folder explicitly when you are scripting it. Passing a second argument names the destination:

degit user/repo my-new-project
degit -r user/repo

The README lists -r as the flag that downloads into a new folder. To pull a single file or a subtree rather than everything, use the files filter with a comma-separated list:

degit user/repo my-project --files README.md,src/index.ts

Pinning to a tag, branch or commit uses the hash syntax on the repository argument:

degit user/repo#v1.0.0

After the command finishes you should have the template's files in the destination and no .git directory among them. The full CLI reference, the ESM API and the degit.json actions are in docs/USAGE.md, which the README links rather than inlining.

Where degit is the wrong tool

The most obvious limitation follows from the design: there is no history. If you want to see how a template evolved, cherry-pick a commit, or keep a remote to pull from later, degit gives you none of that. You get one snapshot and nothing else.

Overwriting is the second boundary. The README's agent skill description says the skill helps avoid overwriting a non-empty destination without confirmation, which implies the CLI itself is not documented as prompting. The README does not document rollback, so if a run writes into a directory that already held files, recovery is your problem, not degit's.

The third boundary is private and SSH sources. They need a local git binary, because the tarball path is not what handles them. If your environment has no git installed and your repository is private, degit will not save you from installing it.

Finally, degit is a scaffolding tool, not a package manager or a dependency updater. It has no concept of a lockfile, no version resolution beyond the ref you name, and no update command. Re-running it against the same destination is a fresh copy operation, not an upgrade.

degit compared with git clone --depth 1 and the tools in its own See also list

The README answers the closest comparison itself, under the heading "Why not just git clone --depth 1?". A shallow clone still creates a .git directory, which you then delete if you are using the result as a template. It also does not cache a tar archive for offline reuse, and it has no equivalent of degit.json actions or the --files filter. What a shallow clone gives you that degit does not is a real repository: a remote, a branch, and the ability to pull again.

The README's See also section names three related projects: zel by Vu Tran, gittar by Luke Edwards, and gitpick by Neeraj Dalal. The README gives no comparison of their approaches, so the honest statement is that they occupy the same problem space and you would need to read their documentation to choose between them.

One difference that is visible in this repository is the agent skill. Degit ships skills/degit/SKILL.md and can be installed into an agent with npx skills add Rich-Harris/degit --skill degit, or with -g for a global install. The skill's stated job is to help an agent choose a source, ref and destination, handle private repositories and aliases, and avoid overwriting a non-empty destination. Whether that matters depends on whether your workflow involves an agent at all; for a human running one command, it is irrelevant.

Maintenance, licence and what an upgrade costs you

The repository is not archived. Its last push was on 2026-09-13, and the most recent release listed is v3.10.0 on 2026-09-06, with v3.9.0 and v3.8.0 both dated 2026-09-04. That is a recent cadence, and the CHANGELOG lives at docs/CHANGELOG.md, which is one of the files published to npm.

Upgrade cost is low for the CLI, because the surface is small: a repository argument, a destination, a ref suffix, --files and -r appear in the README, and the rest is in docs/USAGE.md. The risk sits in the library API and in degit.json. The package is ESM only, so a major bump can change how it is imported from CommonJS, and the schemas/ directory suggests degit.json is validated against a schema that can change shape between majors. Pin the version in CI and read docs/CHANGELOG.md before moving.

The licence is MIT, per LICENSE.md and the license field in package.json. That permits use, modification and redistribution with the licence and copyright notice retained, but this is a description of the licence text, not legal advice for your situation. Note that degit downloads other people's repositories; the licence of the template you pull is a separate question from degit's own MIT terms, and nothing in degit checks or reports it.

Editorial conclusion

Adopt degit if you distribute templates, scaffold projects repeatedly, or want a snapshot of a repository without a .git directory. Do not adopt it if you need commit history, an actual upstream remote, or a working tree you can push from; git clone --depth 1 covers those cases. Before relying on it in a pipeline, verify that Node 20 or later is available, that the target repository is reachable over HTTPS or that a local git binary exists for SSH sources, and that your destination directory is empty, because the README does not document an overwrite prompt.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Rich-Harris/degit on GitHub