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.<p>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.<p>[0] - <a href="https://gokoji.com" rel="nofollow">https://gokoji.com</a>
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?
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 a part of something which could become a very powerful pattern: community-wide templates which include many best practices in a single commit:<p>- Pre-commit hooks for linting/formatting and unit tests.<p>- Basic CI pipeline configuration with at least build, test and release/deploy phases.<p>- Package installation configuration for the frameworks you want.<p>- Container/VM configuration for the languages you want to enable cross-platform and future-proof development.<p>- Documentation to get started with it all.
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 :)
It's nice to have, but it does feel super limited with tools like <a href="https://github.com/tmrts/boilr" rel="nofollow">https://github.com/tmrts/boilr</a> or <a href="https://github.com/audreyr/cookiecutter" rel="nofollow">https://github.com/audreyr/cookiecutter</a> which allows to generate customized files/directories via variables and conditions.
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.<p>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