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.
Working
branch
Propose
Pull
request
Review
main
(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.

💻 Members A, B, and C Each working locally
push
☁️ GitHub (remote) The team's shared latest state

🔑 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.

Working branch
(finished)
Open a
pull request
Changes
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."

CommentRaise a question or suggest an improvement
Change requestedAsk the author to fix an issue
Approval"This looks good to merge"

🔑 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.

Pull
request
Feedback and
fixes repeat
Approved
merge
main
(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:

🏠 Back to top