The Shape of a Team Workflow

Almost every team on GitHub follows the same loop. Before the details, it is worth seeing the whole shape at once — partly because it is short, and partly because most of it is already familiar.

Why not just commit to main?

You have been committing directly to main for six chapters, and nothing went wrong. With a second person, two things change.

main is what the project is. If half-finished work goes there, the version everyone treats as real is half-finished — and on Sandpiper that means the club's site is broken on a Tuesday afternoon for no reason anyone chose.

And there is nowhere for a change to be looked at. Once it is on main, it has already arrived. Any conversation about it is a conversation about undoing something rather than about whether to do it.

The loop

Start from an up-to-date main, work on a branch, push it, propose it, get it read, merge it, tidy up:

git switch main
git pull
git switch -c fix-meeting-time
# edit, then:
git add index.html
git commit -m "Correct the meeting time to Thursday"
git push -u origin fix-meeting-time

Every one of those commands is from Chapters 2, 6 or 7. The only genuinely new step comes next, and it happens on the website.

What a pull request adds

A pull request is a page on GitHub that says: here is a branch, here is what it changes, please look at it and merge it if you agree.

It is not a Git concept. Git only ever sees a branch and, eventually, a merge. What the pull request adds is a place for the change to be read, questioned and improved before it becomes part of the project — which is a social mechanism wearing technical clothes.

That is also why the same idea has different names elsewhere: GitLab calls it a merge request, which is arguably the better name for what it does.

main stays clean by agreement

On a two-person project, "nobody commits to main directly" is an agreement, and nothing enforces it. You could push straight to main tomorrow and Git would not object.

Larger projects enforce it with settings that block direct pushes and require a review before merging. That is real and worth knowing about; configuring it is the deep dive's chapter on branch protection. For Sandpiper, an agreement between two people is enough.

The same loop, alone

It is worth using this loop even when nobody is reviewing anything.

It keeps main working at all times, which means you always have a version you can show someone. It gives each change a written description, which is a second layer of the "why" that commit messages carry. And it means the habit is already in your fingers on the first day of a job, when somebody says "just open a PR" and assumes you know what that means.