Behind every well-ordered GitHub project there's a workflow everyone agreed to follow, and the most common one is simple: one branch per task, every branch reviewed through a pull request, and main kept clean all the time. The point isn't the ceremony, it's that anyone can start work without tripping over someone else's.
About 2 min of reading
Before this new lesson, one small question about the lesson you just finished. Recall it, do not look it up.
I kept merging main into my feature branch at the wrong moment, and the conflict I got later was just friction I had not synced out. Let me run a small team flow myself: one branch per task, keep it current, and open a PR that merges cleanly because I stayed in sync the whole time.
Start a real main with a few commits, then create a task branch. Giving the task its own branch keeps it out of main and makes it easy to trace who did what. The branch name should say what is inside it.
Before you run it, say out loud what it will print. Then open the answer.
Do the actual task work on the branch. While I am away, a teammate keeps merging into main, so main will drift ahead of my branch. That is exactly what makes staying current matter later.
Before you run it, say out loud what it will print. Then open the answer.
While I was working, main moved ahead. Pull their latest into main first, then bring that into my branch and merge, so my work stays in sync. This is the habit that stops small conflicts from building up into a fight later.
Before you run it, say out loud what it will print. Then open the answer.
Push the branch and open the pull request. The branch has the work and main is clean, so the diff the reviewer sees is exactly the search box. I add a short note so anyone reading knows what changed and why.
Before you run it, say out loud what it will print. Then open the answer.
Once a reviewer approves, merge the pull request. The branch joins main and the request closes, so the history now shows exactly what shipped. Because I stayed in sync the whole time, main stays clean and still works.
Before you run it, say out loud what it will print. Then open the answer.
Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.
Give each task its own branch. Work stays separated and every change goes through review, which makes it easy to trace who did what and why.
Require at least one approval before merging. It catches mistakes early and spreads knowledge around the team so no single person holds all the context.
Dev A: branch feature/login
Dev B: branch feature/search
Both: open PRs
Reviewers: approve and merge
main: stays clean and always worksEveryone works on their own branch so the code never blocks on another person. PRs keep reviews fast, and main is always close to shippable. It's an unglamorous setup, which is exactly what makes it reliable across a whole team.
feature/login
fix/search-bug
docs/api-guideA clear branch name tells you what's inside before you open anything. Start with a type, feature/, fix/, docs/: then add a short slug. A new teammate can usually guess the contents from the name alone.
git switch main
git pull
git switch feature/login
git merge mainWhile you're away, teammates keep merging into main. Pull their changes into your branch now and then, so your work stays in sync. It stops surprise conflicts from building up, by the time you open your PR, most of the friction is already gone.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.