Collaboration with GitHub

Git is the tool that records history; GitHub is where people meet around that history. GitHub is a hosted service for sharing Git repositories, discussing changes, and reviewing branches before they land in main.

This lesson moves your local Git workflow onto a team-shaped loop: clone a shared repo, send your branch up, bring teammates' work down, and use pull requests to review before merging.

Remotes and origin

A remote is a named connection from your local repo to another copy of the same Git repo, usually hosted on GitHub. Think of it as the shared library copy of the history notebook: your laptop has one copy, GitHub has another, and Git commands move commits between them.

The default remote name is usually origin, which is just a nickname for the GitHub URL you cloned from. It is conventional, not magic.

$ git clone https://github.com/maya/lunch-menu.git
Cloning into 'lunch-menu'...
remote: Enumerating objects: 18, done.
Receiving objects: 100% (18/18), done.
$ cd lunch-menu
$ git remote -v
origin  https://github.com/maya/lunch-menu.git (fetch)
origin  https://github.com/maya/lunch-menu.git (push)
$ git branch -a
* main
  remotes/origin/main

git clone is a command that copies a remote repository onto your machine and sets up origin for you. A remote-tracking branch is your local record of where a remote branch was the last time Git checked; origin/main is not your editable main, it is your map of GitHub's main.

GitHub accepts two common URL styles. HTTPS URLs start with https:// and work through browser/account credentials. SSH URLs start with git@github.com: and use an SSH key. The daily Git commands are the same either way, so do not turn this into a credential rabbit hole today.

Connect a Local Repo to GitHub

Sometimes you start locally first, then create an empty GitHub repo and connect it. The shape looks like this:

$ git remote add origin https://github.com/maya/lunch-menu.git
$ git remote -v
origin  https://github.com/maya/lunch-menu.git (fetch)
origin  https://github.com/maya/lunch-menu.git (push)
$ git branch -M main
$ git push -u origin main
Enumerating objects: 12, done.
To https://github.com/maya/lunch-menu.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

git remote add is a command that saves a remote nickname and URL in your local repo. git push is a command that sends your local commits to a remote. The -u flag sets an upstream branch, which is the default remote branch Git uses later when you type plain git push or git pull.

The git branch -M main line renames your current branch to main if needed. You normally do this once when connecting an older or freshly initialized repo.

Fetch, Pull, Push

Collaboration has two directions: your commits go up, other people's commits come down.

git fetch is a command that downloads remote branch information without changing your working files. It updates maps like origin/main, so you can inspect what changed before touching your own branch.

git pull is a command that fetches and then merges remote changes into your current branch. Pull changes your working tree, so run it from the branch you mean to update.

$ git fetch origin
From https://github.com/maya/lunch-menu
   17be6bd..65498ae  main       -> origin/main
$ git switch main
Switched to branch 'main'
$ git pull --ff-only
Updating 17be6bd..65498ae
Fast-forward
 menu.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

The --ff-only option tells Git to update only if it can fast-forward. If Git would need to create a surprise merge commit, it stops and asks you to decide deliberately.

For your own work, keep using feature branches:

$ git switch -c add-dessert-menu
Switched to a new branch 'add-dessert-menu'
 
# edit, test, inspect with git diff, then commit
$ git push -u origin add-dessert-menu
To https://github.com/maya/lunch-menu.git
 * [new branch]      add-dessert-menu -> add-dessert-menu
branch 'add-dessert-menu' set up to track 'origin/add-dessert-menu'.

Pushing a branch does not automatically merge it into main. It puts the branch on GitHub so other people can inspect it.

Pull Requests and Code Review

A pull request (often PR) is a GitHub conversation asking to merge one branch into another. It shows the diff, the commits, comments, checks, and the final merge button in one place.

Code review is the practice of another developer reading a proposed change before it lands. Good review is not a trial. It is a second set of eyes on correctness, readability, tests, naming, and risk.

A practical PR loop:

• Create a feature branch from current main.
• Make small commits, run tests, and push the branch to GitHub.
• Open a pull request from your branch into main.
• Respond to comments by pushing more commits to the same branch.
• Merge only after the review is settled and automated checks pass.

Review comments should point at code and explain the reason: "This writes a real .env value into the test fixture" is useful. "Bad" is noise.

Forks and Contributions

A fork is your own GitHub copy of someone else's repository. Use a fork when you do not have permission to push branches to the original project.

A branch is a line inside one repo. A fork is a whole repo copy under a different account. That distinction matters: teammates usually collaborate with branches in the same repo; outside contributors usually work through forks.

$ git clone https://github.com/maya/lunch-menu.git
$ cd lunch-menu
$ git remote -v
origin  https://github.com/maya/lunch-menu.git (fetch)
origin  https://github.com/maya/lunch-menu.git (push)
$ git remote add upstream https://github.com/original-org/lunch-menu.git
$ git fetch upstream
From https://github.com/original-org/lunch-menu
 * [new branch]      main       -> upstream/main

upstream is the common remote nickname for the original repo your fork came from. Your origin points to your fork, where you can push. upstream points to the original, where you fetch updates and target pull requests.

When contributing to another project, the safe shape is: fork on GitHub, clone your fork, add upstream, create a branch, commit, push to your fork, then open a PR back to the original repo. CI and automation take over in the next lesson.

You now have the collaboration loop: clone, branch, fetch, pull, push, and review through PRs. Next you'll make GitHub run tests and checks automatically with CI/CD.