Week 3: GitHub Collaboration & Pull Requests

1. Git vs. GitHub & Setting Up SSH

Git is the version control tool; GitHub is a company that hosts Git repositories and layers collaboration features on top — pull requests, issues, code review, CI, and more. GitLab and Bitbucket are competing hosts built on the same underlying Git; nothing about Git itself is GitHub-specific.

Authenticate with an SSH key so you're not typing a password or token on every push. Generate one, then add the public half to your GitHub account:

ssh-keygen -t ed25519 -C "ada@example.com"
# Accept the default file location; a passphrase is optional but recommended.

cat ~/.ssh/id_ed25519.pub
# ssh-ed25519 AAAA... ada@example.com
# Copy this entire line into GitHub -> Settings -> SSH and GPG keys -> New SSH key

ssh -T git@github.com
# Hi ada! You've successfully authenticated...

2. Remotes: clone, push, pull & fetch

A remote is a named reference to a repo hosted elsewhere — origin is the conventional name for the one you cloned from or push to by default.

# Starting from an existing GitHub repo:
git clone git@github.com:your-user/hello-git.git
cd hello-git
git remote -v
# origin  git@github.com:your-user/hello-git.git (fetch)
# origin  git@github.com:your-user/hello-git.git (push)

# Or wire up a remote to a repo you already have locally:
git remote add origin git@github.com:your-user/hello-git.git
git push -u origin main   # -u remembers this as main's default remote/branch

fetch, pull and push are the three commands that move history between local and remote:

git fetch origin          # download new commits from origin, but don't merge them
git log origin/main       # inspect what's new before touching your own branch

git pull                  # fetch AND merge (or rebase) into your current branch, in one step
git push                  # upload your local commits to the remote

3. Forking & the Fork-and-PR Workflow

A fork is your own personal copy of someone else's repository on GitHub. It's the standard way to contribute to a project you don't have write access to — you can't push directly to their repo, so you push to your fork instead, then ask them to pull your changes in via a pull request.

# 1. Click "Fork" on GitHub, then clone YOUR fork:
git clone git@github.com:your-user/some-project.git
cd some-project

# 2. Add the original repo as a second remote, conventionally named "upstream":
git remote add upstream git@github.com:original-owner/some-project.git

# 3. Branch, commit, push to YOUR fork (origin):
git switch -c fix-typo
# ... edit files ...
git commit -am "Fix typo in README"
git push -u origin fix-typo

With upstream wired up, keeping your fork current is a fetch-and-merge (or rebase) against upstream/main, exactly like syncing any other remote branch:

git fetch upstream
git switch main
git merge upstream/main
git push origin main    # keep your fork's main in sync too

4. Opening & Reviewing Pull Requests

A pull request (PR) proposes merging one branch into another and opens a dedicated space for discussion, line-by-line comments, and automated checks, before anything actually merges. On GitHub, after pushing a branch:

1. GitHub shows a "Compare & pull request" prompt for the branch you just pushed — or open one manually from the Pull Requests tab.
2. Pick the base branch (usually main) and the compare branch (your feature branch), write a clear title and description of what changed and why.
3. Request reviewers. They can leave comments on specific lines, approve, or request changes.
4. Push more commits to the same branch to update the PR automatically — no need to open a new one.
5. Once approved (and checks pass, covered in Week 5), merge via GitHub's "Merge pull request" button — a standard merge, squash, or rebase merge, depending on the repo's convention.

5. Issues, Labels & Linking Commits

GitHub issues track bugs, feature requests and tasks — independent of any specific branch or commit. Reference an issue number in a commit message or PR description to link them automatically, and certain keywords auto-close the issue when the PR merges:

git commit -m "Fix null pointer on empty cart (fixes #42)"
# In a PR description, any of these auto-close issue #42 on merge:
# Closes #42 / Fixes #42 / Resolves #42

Labels (bug, enhancement, good first issue) and assignees turn a flat issue list into something a team can actually triage and plan around — most repos also use a Project board to arrange issues into a Kanban-style view.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.