Working with Others

01 Adding Collaborators to a Private Repo

For a small project — you and a few friends or teammates — direct collaborator access is the simplest option:

• Open the repo on GitHub → Settings → Collaborators.
• Click Add people and search by their GitHub username or the email on their account.
• They'll get an invite email or notification, which they need to accept before they get access.
• Once accepted, they can clone the repo with their own GitHub login and push directly — no forking needed.

02 Organizations & Teams

For anything bigger than a handful of people, create a GitHub Organization instead of adding collaborators one by one to each personal repo:

• From the + menu top-right → New organization — free plans cover most student and small-team needs.
• Repos live under the organization (github.com/your-org/project) instead of a single person's account, so the project survives even if someone leaves.
• Create Teams inside the org (e.g. "frontend", "backend") and grant a team access to specific repos at once, instead of managing each person individually.
• The same permission levels from above (Read → Admin) apply per team, per repo.

03 Pull Requests — Proposing Changes

Even with push access, the standard workflow on a team is to never commit straight to main. Instead, you work on a branch (a separate copy of the project to work in safely) and open a Pull Request, or PR for short — a request asking for your branch to be merged into main — this is what gives teammates a chance to review before anything lands.

Opening a PR from the GitHub website

• Push your branch: git push -u origin feature/login-page
• GitHub shows a yellow banner on the repo page: "Compare & pull request" — click it.
• Write a clear title and description of what changed and why, then click Create pull request.

Opening a PR from the terminal (GitHub CLI)

--fill uses your branch name and commit messages to auto-fill the title and description, so you can skip typing them out again.

04 Reviewing & Merging

• On the PR page, click Reviewers and pick a teammate — they get notified.
• A reviewer can leave inline comments on specific lines, then Approve, Request changes, or just Comment.
• From the terminal, a reviewer can pull down the PR's branch to test it locally before approving: gh pr checkout 42 (where 42 is the PR number).

When it's approved, you'll get three merge options on GitHub:

• Merge commit — keeps every individual commit plus a merge commit tying them together. Full history, a bit noisy.
• Squash and merge — combines all the branch's commits into a single clean commit on main. Most teams default to this for tidy history.
• Rebase and merge — replays the branch's commits onto main individually, no merge commit at all. Keeps history linear.

05 Resolving Merge Conflicts

A conflict happens when two people change the same lines of the same file differently. Git can't guess which version you want, so it stops and asks you. This is normal — it doesn't mean anything is broken.

After a git pull or git merge that hits a conflict, the affected file will contain markers like this:

• Everything between <<<<<<< HEAD and ======= is your current version.
• Everything between ======= and >>>>>>> is the incoming version.
• Edit the file by hand to keep whichever line (or a mix of both) is correct, then delete all three marker lines completely.

Once every conflicted file is cleaned up:

06 Contributing to Someone Else's Project

If you don't have write access to a repo — most open-source projects — the workflow is fork first, PR last. (Forking means making your own copy of someone else's repo under your own account — covered fully in Part 2 if you haven't done it before.)

• Click Fork on their repo to get your own copy under your account.
• Clone your fork locally and create a branch for your change.
• Commit and push to your fork, then open a PR — but this time GitHub targets it from your fork's branch back to the original project's main branch.
• Keep your fork in sync with the original as it moves on, so your PR doesn't fall too far behind. upstream here is just a common nickname for "the original repo I forked from" — not a special Git keyword, you could name this remote anything:
  terminal

  $git remote add upstream https://github.com/original-owner/project.git

  $git fetch upstream

  $git merge upstream/main

07 Issues & Projects

Issues are GitHub's built-in ticket system — use them to track bugs, feature requests, or tasks. Anyone with access can open one from the Issues tab, assign it to someone, label it, and reference it directly from a commit or PR by writing #12 (issue number) — GitHub auto-links it. Write Closes #12 in a PR description and merging that PR will close the issue automatically.

Projects is a Kanban-style board (To do / In progress / Done) you can attach issues and PRs to, giving the whole team a visual overview of what's being worked on — find it under the Projects tab on a repo or organization.

08 Protecting the Main Branch

Once a team is pushing regularly, it's worth stopping accidental direct pushes to main. Under Settings → Branches → Add branch protection rule, you can require:

• At least one approving review before a PR can be merged.
• Status checks to pass first — automated checks (usually tests) that run on every push, often set up with GitHub Actions (see Part 5). A red ✗ next to a PR means a check failed and it can't be merged yet.
• No one — including admins — to push directly, forcing everything through a PR.

This is usually the first setting a team enables once more than two people are pushing to the same repo.

09 Collaboration Cheat Sheet