Many people are familiar with the idea of the template repository. It provides a great way to centralize configurations for common projects for teams. I can declare a repository, configure it with files and folders, and set up one or more branches. After marking it as a template in the Settings, it becomes available to other team members when they create a repository.
As an example, if I create a new repository called my-template and configure it as a template, creating a new repository will show me an option to use that to define the contents.
There’s a fun trick hidden in this functionality that you may not realize is there. When a new repository is created from a template, GitHub will push a copy of the repository (and optionally, its branches) to the new location. If there are any Actions configured in that repository, the events will still be triggered. That means that create will trigger for the branches being created (including main) and push will trigger for the code being updated in the repo.
Knowing this, it’s possible to do advanced configuration on the repository. For example, you could perform some additional commits, create an initial issue, or dynamically create or alter workflows. The full functionality is available!
Just because you can doesn’t mean you should (or that it’s the right choice). In most cases, it’s easier (and more intuitive) to handle these steps from outside the repository. For example, you could use IssueOps or ApproveOps to allow users to request new repositories. Based on that process, the workflows in that repository can provision and configure a repository. In addition, this approach allows users to supply additional details that can be used to customize the repo.
All of that said, there can be situations where having a standalone template with additional functionality can be helpful. Now you have one more option at your disposal.