Working with GitHub Repositories
Creating and configuring
A repository can be created from scratch, from a template repository, or by forking an existing project. When creating one you choose visibility (public or private), optionally add a README, a .gitignore template, and a license. Settings let you rename the repo, change the default branch, transfer ownership, archive it (read-only, keeps history), or delete it.
Fork vs clone - the classic trap
A fork is a server-side copy of someone else's repository placed under your account, keeping a link to the original (upstream) so you can open pull requests back to it. A clone is a local copy on your machine. Forking happens on GitHub; cloning happens with Git. Syncing a fork means pulling from upstream, not from origin.
Branches and protection
Work happens on branches; the default branch is what the repository shows first and what most pull requests target. Branch protection rules can require pull request reviews, passing status checks, signed commits, or linear history, and can block force pushes and deletions. Rulesets are the newer mechanism with similar intent.
Files that shape a repository
The README.md renders on the repository home page. .gitignore keeps untracked files such as build output out of commits. A license file declares how others may use the code. Topics, descriptions, and social preview images affect discoverability, not permissions.
Worked example
You want to fix a bug in a project you do not own. Fork it to your account, clone your fork, create a branch, commit, push to your fork, then open a pull request from your branch to the upstream default branch. You cannot push directly to the upstream repository unless you have been granted write access.