This is awesome! I've been working on something similar with Koji [0], with the added twist of taking templates for full stack (web) apps and cloning remote dev environments + production deployment pipelines alongside the code. It's been especially valuable for more junior devs/people just getting started to be able to "play" and remix an app instead of trying to start building from scratch. Especially when some of them have never even heard the word "repository" before.
There's a lot of interesting stuff that comes when thinking about these kinds of templates from the level of fully-baked products instead of just lower-level components like frameworks and libraries. Excited to see where Github is headed with all of these recent feature releases.
Here is some constructive feedback. A few things that I wanted to see when I looked at the website: a "how it works" page with technical information; an explanation of how multi-environment templates with deployment pipelines work; ability to view the template source before I deploy. From 60 seconds browsing the site (which is about how long someone will spend before closing the tab and moving on) I can't tell exactly what the project does (what is the local dev environment like? How does deployment work? Is it self hosted? Does it support cloud deployments?), and looking at the details page for a template doesn't let me preview the source or see what the components are. For example, the microblogging template; what language is it written in? What does it use for a server? Does it use frameworks for the client and back-end? Does it use a database? I have literally no idea what will happen if I click on the "Use Template" button, and I'm unlikely to create an account just to find out.
I really appreciate your taking a look and writing all of that up. We're only a month or so into public beta, so a lot of things (mainly on that technical documentation side that you mentioned) are still missing. We've been heavily focused on enabling non-technical people, or very early beginners, to use the platform as creators, so we've been a little hesitant to overwhelm them with technical things that might scare them off or make it seem like this isn't a tool for them. That being said, you're absolutely right that it's a huge piece of this (and arguably the most important piece for a certain audience) and part of a balance we need to find moving forward. If you're curious about the answers to those questions, there's a low-level technical writeup on this page [0] that I'm working on incorporating somewhere into the actual product/landing page.
I don't understand. What's the difference between this and just cloning (not forking) a repo? If it's the same, why not just add a button called "clone" that appears in _all_ repos?
When you fork a repository on Github, the website retains the association between the original and forked repos. But there are also artificial limitations e.g. Github forks can't be private when there's no technical reason that couldn't be the case. A forked repo is fundamentally just a clone with a different origin (i.e. changes get committed to a new place). What we think of as "forking" is the user experience that services like Github provide. If you clone a repository and then make a new project on Github with it, Github has no way of identifying that what you've done is technically a fork. It could obviously, but it doesn't.
Templating is basically the same thing, but it's more like clone a repository, delete the .git folder, run git init, and then associate the repo with your account. Except this all happens transparently on Github's servers and what you end up with is a clean new project with an "initial commit".
So in a sense whether you fork or template, you're still cloning a repo, but what happens after you clone is different in each case (and is also different from "just" cloning).
The biggest benefit will probably be for new programmers following a tutorial that provides a template. The word "clone" means nothing to them. They just want to copy and build off of this project on their own GitHub.
Yes, it does sacrifice some learning about git, but once you get someone hooked on programming they will be able to learn the tools later.
No, this does not preserve the history of the repo, just gives a single commit with the existing files. You might also think of this as cloning, then squashing down the entire history (well, everything in master anyways) to a single (root) commit.
I've been using cookiecutter for this mostly.
But in general I feel like excessive boilerplate is more like a code smell. Reusable code should live in libraries, and frameworks should have sane defaults and configuration be kept to a minimum.
This is useful for boilerplate code. But keeping it in sync with upstream isn’t possible due to it having a single initial commit and separate history. For that a fork is the only choice. I see how the use cases can pan out for templates. Glad that Github is releasing more features off late :)
This is a great improvement. The inability to fork within an organization always made bootstrapping new projects from a template just ever so slightly too annoying.
Sounds pretty awesome. I'd especially love it if frameworks like Spring offered releases via this channel.
I'd be curious to see how composability works with this, too: if for instance I wanted to make a React+Rails boilerplate, it'd be awesome if users could cherry-pick a commit to use it with their Bugsnag+Rails boilerplate.
I played with this this week. I like it! I wish it kept the branch protection rules and the like if the new repo is in the same org, but overall, good times
There's a lot of interesting stuff that comes when thinking about these kinds of templates from the level of fully-baked products instead of just lower-level components like frameworks and libraries. Excited to see where Github is headed with all of these recent feature releases.
[0] - https://gokoji.com