3.2. Creating and Organizing Repositories
Starting a new repository from a blank slate isn't the only option, and picking the right starting point saves real setup work.
💡 First Principle: A repository can start from nothing, or it can start from a template repository — a reusable blueprint that copies its file structure, branches, and settings into a brand-new repository with no shared history to the original. That last part matters: unlike a fork, a repository created from a template has a clean, independent commit history, because it's meant to be the start of something new, not a contribution back to the source.
Every repository is also created with one default branch — main, unless renamed — which becomes the baseline that the GitHub Flow (2.2) builds around. Organizing a repository well from the start (a clear default branch, a template where one applies, sensible top-level folders) pays off every time someone new clones it — which is itself a fourth option worth distinguishing from the three above: cloning doesn't create a new repository on GitHub at all, it downloads an existing one to your local machine. Forking creates a new, connected copy on GitHub's servers; cloning creates a local working copy of a repository you already have access to.
⚠️ Exam Trap: A repository created from a template starts a fresh, independent commit history — it is not connected back to the template's history the way a fork stays connected to its upstream source. Don't confuse either of those with cloning: cloning is a local download of a repository that already exists, not a way to create a new one on GitHub.
Reflection Question: Your team keeps recreating the same folder structure, CI config, and license every time it starts a new microservice. Which repository creation option removes that repeated setup work?
