Forks turn collaboration into request, not push
The fork-and-pull workflow is how the open-source world contributes to projects that contributors do not have direct write access to. The shape: copy the project to your account (a fork), make changes on a branch in your fork, then ask the original maintainers to pull those changes via a Pull Request. The original repo never grants you push access; the PR mechanism is the request-and-review channel that replaces direct push.
Mechanically: GitHub's "Fork" button creates a server-side copy under your account. You clone your fork locally and add the original repo as a second remote, conventionally named upstream. Daily flow: fetch from upstream, sync your fork's main branch, branch off for new work, push the new branch to your fork, open a PR on GitHub. The PR description is where you make the case — what changed, why, how to verify, what risks.
Keeping your fork in sync matters because PRs against an old base produce false conflicts. The clean dance: git fetch upstream, git switch main, git rebase upstream/main, git push origin main. Now your fork's main mirrors the original. Branching off main from this point yields PRs that apply cleanly. GitHub's web UI also offers a "Sync fork" button that does the equivalent without a terminal.
The PR itself is the social product. Title in imperative, ideally with a Conventional Commits prefix. Description with real sections: what, why, how to test, screenshots if visual, breaking changes if any. Link the issue. Keep PRs focused — one concern per PR. Reviewers comment, you push more commits to the same branch (which automatically updates the PR), and once approved, a maintainer merges. After merge, delete the branch on both sides; your fork's main syncs with the new history on next pull.