Applied AI / Git, GitHub & GitHub Copilot / Module 07 · Collaboration: Pull Requests, Issues & Reviews
Module 07

Collaboration: Pull Requests, Issues & Reviews

Developer Tools Git, GitHub & GitHub Copilot

Module 07 — Collaboration: Pull Requests, Issues & Reviews

Goal: Work the way real teams (and open-source projects) do — forks, branches, pull requests, code review, and a first taste of automation with GitHub Actions.

7.1 The collaboration model in one picture

  Issue (describe the work)
        │
        ▼
  Branch (do the work)  ──►  Commits  ──►  Push to GitHub
        │
        ▼
  Pull Request (propose the change)
        │
        ▼
  Review + automated checks  ──►  Merge into main  ──►  Delete branch

Every change of consequence flows through this loop. Let’s unpack each piece.

7.2 Issues — tracking what needs doing

An issue is a discussion thread for one task: a bug, a feature request, a question. It has a title, a description, labels (bug, enhancement), assignees, and a number (#42). Issues are how teams decide what to work on before any code is written. You can reference them in commit messages and PRs; writing Fixes #42 in a PR auto-closes that issue when the PR merges.

7.3 Two collaboration setups

Shared repository (teams)

Everyone has write access to one repo. You create a branch, push it, and open a pull request against main. This is typical inside a company.

Fork & pull (open source)

You don’t have write access to someone else’s project, so you fork it — make your own full copy under your account.

# After clicking "Fork" on GitHub:
git clone git@github.com:you/their-project.git
cd their-project
git remote add upstream git@github.com:original-owner/their-project.git

Here origin is your fork and upstream is the original. You branch, push to your fork, then open a PR into the original. You keep your fork current by pulling from upstream:

git fetch upstream
git merge upstream/main

7.4 The pull request (PR) — the heart of GitHub

A pull request says: “I have some commits on a branch; please review them and merge them into yours.” A PR is not a Git feature — it’s a GitHub feature built around Git branches.

Typical flow:

git switch -c fix-typo
# ...edit, then...
git add .
git commit -m "Fix typo in onboarding text"
git push -u origin fix-typo

GitHub then shows a “Compare & pull request” button. Opening the PR gives you:

  • A diff of every change.
  • A space for discussion and line-by-line review comments.
  • Automated status checks (tests, linters) that must pass.
  • Approvals from reviewers.
  • A merge button when everything’s green.

Merge strategies on GitHub

When merging a PR, GitHub offers three styles:

  • Create a merge commit — preserves all your commits plus a merge commit (full history; Module 05).
  • Squash and merge — combines all the PR’s commits into one tidy commit on main. Most popular for keeping history clean.
  • Rebase and merge — replays your commits onto main with no merge commit.

After merging, delete the branch — its pointer is no longer needed, and the commits live on in main.

7.5 Reviewing code well

Good reviews catch bugs and spread knowledge. As a reviewer: read the diff, leave specific comments, ask questions, and either Approve, Request changes, or Comment. As an author: respond to every comment, push follow-up commits (the PR updates automatically), and don’t take feedback personally — it’s about the code.

This is also where GitHub Copilot increasingly helps: Copilot can review a PR and leave suggestions automatically, and it can summarize what a PR does. We get to Copilot in Part C.

7.6 A first look at GitHub Actions (automation)

GitHub Actions runs automated jobs in response to events. You define a workflow as a YAML file in .github/workflows/. Example: run tests on every push.

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]      # events that trigger this
jobs:
  test:
    runs-on: ubuntu-latest     # a fresh virtual machine
    steps:
      - uses: actions/checkout@v4      # check out your code
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm install
      - run: npm test                  # fail the check if tests fail

Now every push and PR runs your tests automatically; the result shows up as a green check or red X on the PR. This is continuous integration (CI) — catching breakage early and automatically. Actions can also deploy, publish packages, label issues, and much more.

Note the folder: .github/. This same special folder is where Copilot’s customization files live (Modules 11–12). GitHub treats .github/ as the home for repo configuration.

Try it yourself

  1. On a GitHub repo, open an issue describing a small change.
  2. Create a branch, make the change, push it, and open a pull request that says Fixes #<your issue number>.
  3. Leave a review comment on your own PR, then resolve it.
  4. Merge the PR using Squash and merge and confirm the issue auto-closed.
  5. Add the ci.yml workflow above (adjust to your language) and watch the check run on your next push.

Key takeaways

  • Work flows: issue → branch → commits → pull request → review + checks → merge → delete branch.
  • Forking lets you contribute to repos you can’t write to; keep your fork synced via an upstream remote.
  • A PR is GitHub’s review-and-merge layer around a Git branch; merge styles are merge / squash / rebase.
  • GitHub Actions automates testing and deployment via YAML in .github/workflows/.

Next: Module 08 — Undoing Things & Recovery

← Module 06: Remotes & GitHub