Collaboration on GitHub
Key points
- GitHub is a service that shares a Git repository over the internet and helps teams develop together.
- The basic flow is to propose a change as a "pull request," have other members do a "code review," and only then merge it into the main line.
- This mechanism keeps a single person's blind spot from letting problematic code slip through unchecked.
branch
request
(after merge)
The role of the remote repository
Git's history exists on each member's own machine (locally), but that alone doesn't pull the team's work together into one shared result. GitHub serves as the place to host the team's common "remote repository," gathering everyone's changes into a single location.
🔑 A familiar exampleThink of it like a shared folder in the cloud. Everyone works on their own computer, then ultimately gathers their work in the same place so the whole team can reference the same up-to-date version.
What is a pull request?
A pull request (often shortened to "PR") is a mechanism for proposing to the team, "please merge the changes from this working branch into main." GitHub lets you review the full diff of the proposed changes in one place.
(finished)
pull request
presented together
Rather than applying changes straight to main, framing them as a "proposal" first gives other members a chance to review the content.
How code review works
Once a pull request is opened, other members read through it, leaving comments and requesting changes where needed. This process is called "code review."
🔑 A familiar exampleIt's like not finalizing a proposal alone and submitting it immediately, but instead going through "draft proposed → everyone reviews → concerns are raised → revisions made" before it becomes official. A second pair of eyes catches things you might have missed.
From approval to merge
If reviewers raise concerns, the original author updates the working branch and asks for another look. This repeats until a reviewer gives their "approval," at which point the pull request is merged into main.
request
fixes repeat
(after merge)
This whole cycle ensures that only "changes the team has reviewed" ever make it into main.
Tracking work with issues
GitHub also has a feature called "issues" for recording bug reports and tasks. A common workflow is to first lay out "what needs to be done" as an issue, then create a pull request that addresses it.
Referencing the relevant issue number in a pull request's description makes it clear to the team which piece of work it's addressing.
🔑 A familiar exampleThink of writing your team's to-do items on a task list, and once someone picks one up, linking their finished work back to that item.
Summary
Collaborating on GitHub follows a basic flow: share changes through the remote repository, propose them as a pull request, and merge into main only after code review. This mechanism lets a team develop in parallel while keeping quality high across the board.
Related topics: