Capstone: collaborate as a four-developer team

Four developers share one private or public repository. Each must learn local Git first, then demonstrate how independent branches become reviewed work in the shared GitHub repository.

Developer A initializes or clones the project and creates a baseline. Developers B, C and D clone the same GitHub repository. Each creates a task branch from an updated main, commits locally and pushes only that branch.

Pull requests become the integration boundary. Reviewers inspect changes and CI. When branches overlap, the author updates and resolves conflicts. After approved PRs merge, everyone updates local main before starting new work. A final version tag and GitHub Release mark the completed iteration.

Run this in a disposable practice repository unless the lesson explicitly says otherwise.

# Every developer, before starting a new task
git switch main
git pull --ff-only
git switch -c feature/<task>

# Work locally
git add <paths>
git commit -m "Describe the task"
git push -u origin feature/<task>

# Open PR, review, fix, merge
# Then update local main again before the next task

The exact branch naming and merge policy can vary, but every person should be able to explain what exists locally, what exists on GitHub and which operation moves information between them.

Your task: Assign four tasks: README update, search feature, validation fix and CI workflow. Each developer creates a branch and PR. Intentionally create one text conflict between two branches and resolve it without deleting either developer's required change.

Do not let the demonstration turn into four people committing directly to main. The purpose is to make branching, remote synchronization, review and conflict resolution visible.

Capstone: collaborate as a four-developer team is complete when you can explain the state being changed before you run the command, not merely repeat the syntax.

Read further: official supporting documentation.