Branch, push, pull request

The feature-branch workflow

On a real team, almost nobody commits straight to main. The shared main must always work, it's what gets deployed. Instead, every change follows the same loop:

1. Branch: git switch -c add-search (lesson 5-2).
2. Commit your work on that branch, small and often (lesson 2-3).
3. Push the branch: git push -u origin add-search (lesson 7-2). main is untouched.
4. Open a pull request on GitHub: a request that your branch be pulled into main.
5. Review: teammates read your changes, comment, and ask for tweaks (next lesson).
6. Merge: a button on GitHub merges the branch into main, everyone pulls the new main.

Steps 4 through 6 happen on the GitHub website, not in your terminal. A pull request (PR) isn't a Git command, it's GitHub's collaboration layer wrapped around the git merge you learned in lesson 5-3, adding a place to see the diff, discuss it, and approve it.

Forks: contributing without permission

The workflow above assumes you're allowed to push branches to the repository. For open-source projects you don't own, you aren't. The answer is a fork: your own complete copy of the repository under your GitHub account, made with the Fork button.

The loop grows by one hop: fork the project, clone your fork, branch, commit, push to your fork, then open a pull request from your fork's branch to the original project. The maintainers review and merge exactly as teammates would.

This is how strangers safely collaborate on Linux, Python, React, and the rest of open source: nobody needs push access to propose a change, and maintainers keep the only keys to main.