Title: Lecture 8 — From Local Commits to Shared Repositories
Course: AIINFRA 100: AI Systems & Development Environments > Section: Week 08 — Collaborative Development with GitHub — Midterm

📖 Lecture — From Local Commits to Shared Repositories

Back in Week 7 you learned to commit changes to your local Git repository. Those commits lived only on your machine. This week we connect that local history to a shared repository on GitHub, and learn the workflow teams actually use to collaborate on code without stepping on each other's work.

What is a "remote"?

A remote is simply a named pointer to a repository hosted somewhere else — most commonly on GitHub. When you clone a repository, Git automatically creates a remote called origin that points back to the repo you cloned from. You can have more than one remote (for example, origin for your own fork and upstream for the original project), but origin is the one you will use most often this week. Three commands move history between your local repo and a remote:

Command | What it does | When you use it
git fetch | Downloads new commits and branches from the remote, but does not change your working files | Checking what's new before you decide how to merge it in
git pull | Runs git fetch and then merges the remote changes into your current branch in one step | Bringing your local branch up to date with the remote
git push | Uploads your local commits to the remote so others (and GitHub) can see them | Sharing your finished commits after you've committed locally

This is the missing link between Week 7 and today: commits are still made locally with git commit, but now git push is what makes them visible to your team on GitHub.

The standard collaboration flow

Almost every team on GitHub follows the same basic pattern:

1. Fork or branch — create your own copy of the repo (fork) or a new line of development inside the same repo (branch).
2. Commit changes — make your edits and commit them locally, just like in Week 7.
3. Push — upload your branch to GitHub with git push.
4. Open a pull request (PR) — propose that your changes be merged from your feature branch into the base branch (often main).
5. Discuss and review — teammates read the diff, leave comments, and request changes if needed.
6. Merge — once everyone is satisfied, someone with permission merges the PR into the base branch.

A pull request is really a conversation plus a diff, not a merge itself — nothing changes in the base branch until a person explicitly clicks Merge pull request.

Issues, code review, and GitHub Actions

Issues are GitHub's built-in tracker for bugs, feature requests, questions, or any task worth writing down. Issues can be assigned, labeled, and linked to pull requests: if a PR description includes a phrase like "Closes #12", merging that PR will automatically close issue #12, keeping your task list and your code changes connected. Code review happens as inline comments directly on a pull request's diff — reviewers can comment on a specific line, suggest a change, or approve the PR. Good review focuses on the design, correctness, and clarity of the code, not the person who wrote it. Expect it to be iterative: you push small follow-up commits that address feedback, and the PR updates automatically. GitHub Actions is GitHub's built-in CI/CD (continuous integration/continuous delivery) system. You describe a workflow in a YAML file stored at .github/workflows/, and GitHub runs it when a trigger happens — most commonly "on every push" or "on every pull request." Think of it as a robot that checks your code every time you push: it might run a linter, run your tests, or just confirm the code still compiles. You'll build your first tiny workflow in this week's lab.

Merge conflicts and two common mix-ups

Sometimes two people edit the same lines and GitHub can't automatically combine the changes — that's a merge conflict. For simple, line-level conflicts, GitHub's web UI lets you resolve them in the browser. Anything more complex should be resolved locally, using the command line or VS Code skills you built in Week 7, then pushed back up.

- "Isn't a fork the same as a branch?" Not quite. A fork is a full copy of the repository under your own GitHub account — you use it when you don't have push access to the original repo. A branch is a separate line of development within the same repository — you use it when you already have push access and just want to isolate your changes. This week's lab uses forking specifically because you won't have push access to the shared practice repo.
- "Doesn't opening a pull request merge my changes right away?" No — opening a PR only proposes the merge and opens it up for review. Nothing in the base branch changes until someone with permission clicks Merge pull request.