3.1. Repository Structure and Key Files
GitHub recognizes a handful of specially named files anywhere in a repository and treats them differently from ordinary files — rendering them, surfacing them, or using them to drive automated behavior.
💡 First Principle: These special files exist so that both GitHub's interface and the people visiting a repository know what to do without being told individually — GitHub looks for them by exact filename and wires up specific behavior around each one. Skip them, and a repository still works technically, but loses the automatic guidance and legal clarity they provide.
| File | What It Does |
|---|---|
README | Renders automatically on the repo's home page — the project's front door |
LICENSE | States the legal terms under which others may use, modify, or redistribute the code |
CONTRIBUTING | Explains how outside contributors should propose changes |
CODEOWNERS | Maps file paths to people/teams who are auto-requested as reviewers on matching pull requests |
SECURITY | Tells researchers how to responsibly report a vulnerability |
⚠️ Exam Trap: A public repository with no LICENSE file is not automatically free to reuse. Default copyright law applies until an explicit license says otherwise — visibility and usage rights are separate things (see 8.1 for more on this).
Reflection Question: A repository has a CODEOWNERS file mapping /frontend/ to one team and /backend/ to another. What happens automatically when someone opens a pull request that only touches files in /frontend/?
