Generate new repositories with repository templates | Hacker News Reader

Generate new repositories with repository templates

github.blog

146 pointsmxstbr24 comments

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.

[0] - https://gokoji.com

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.

[0] - https://stackoverflow.com/jobs/companies/koji-web-app-develo...

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.

I don't get it either, is it literally the same thing a a a clone with a different name?

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.

Maybe I remember incorrectly, but I thought the template came from the default branch?

Oh I get it now, thanks!

Templates are a copy of a non empty word document

Cloning is a word document with versions turned on that copied all the previous versioning information

Wouldn't clone keep the entire history of the original repo, while this gives a single initial commit?

'git clone --depth=1' will only clone the latest HEAD so you won't get the history.

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:

- Pre-commit hooks for linting/formatting and unit tests.

- Basic CI pipeline configuration with at least build, test and release/deploy phases.

- Package installation configuration for the frameworks you want.

- Container/VM configuration for the languages you want to enable cross-platform and future-proof development.

- 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 :)

Agreed. Even as limited as it is it's a great feature

It's nice to have, but it does feel super limited with tools like https://github.com/tmrts/boilr or https://github.com/audreyr/cookiecutter 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.

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

Would love to see templates for reproducible science.

Check out: https://drivendata.github.io/cookiecutter-data-science/

Not a GitHub template, but hits a lot of the same use cases.

Thanks! Looks good. Is there anything against this being also a github template?

Reply on news.ycombinator.com