No. GitHub describes a repository created from a template as a new project that starts with a single commit, with no shared history. Do not expect template changes to reach repositories already created. To keep a golden path current, put the moving parts in shared workflows or shared configuration.
What the documentation says
GitHub's documentation explains that you can generate a new repository with the same directory structure and files as a template repository. It contrasts that with forking: a fork includes the entire commit history of the parent, while a repository created from a template starts with a single commit. It also notes that branches created from a template have unrelated histories, so you cannot create pull requests or merge between them.
The docs do not describe an ongoing link that pushes template changes into repositories created earlier. Plan on the assumption that there is none, and check the current documentation for your platform, since features change.
Why that matters for security
Imagine your template includes a pipeline file with a dependency check, and last month you improved the check. Services created before the change still carry the old file. The more services you have, the more mixed versions you end up with. A vulnerability in the template's own steps, for example an outdated action, would remain in every copy.
Keep the template thin
The fix is to keep as little logic as possible in the copied files, and as much as possible in places you can change centrally.
| Where it lives | How a fix reaches existing repos |
|---|---|
| Template files copied to each repo | It does not, unless someone updates each copy |
| Shared pipeline or workflow called by each repo | Change it centrally, or release a new version |
| Central policy bundle pulled in CI | Release a new version and teams move to it |
| Organisation level repository rules | Applied to matching repositories by the platform |
A good template contains the folder layout, a short pipeline file that calls a shared workflow, a policy reference and a readme. Almost everything that changes lives elsewhere.
Updating the copies you cannot avoid
Some files will always be copied. For those:
- Keep a changelog for the template. Teams can see what changed and when.
- Know which repos came from which version. Add a small marker file or a topic tag when you create a repo.
- Open update pull requests. A script can propose the new file to each repository, and owners review and merge.
- Set a deadline for critical fixes. Track the stragglers.
- Scan the estate. An inventory of dependencies and configurations reveals which repos still carry old files.
Try it yourself
Seeing every service and what it depends on in one place is the quickest way to find stale copies.
Click through it at your own pace, or open it full screen. Notice how a single component can be traced across every project that uses it.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and asset discovery show what each repository contains, so you can find services that still use an outdated component or configuration. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a template repository the same as a fork?
No. A fork carries the parent's commit history. A repository created from a template starts with a single commit and unrelated history.
What should never be hard coded in a template?
Anything you may need to change across all services at once, such as scan versions, policy rules and shared settings. Reference them from a central place instead.
Sources
Last reviewed: 19 October 2026.
