Remote Repositories, Push, Pull & Collaboration

Required tools

• Git (2.x or newer)
• A terminal (or Git Bash on Windows) (any current version)

Setup

1. Open a terminal.
2. Create a dedicated, disposable practice folder: `mkdir git-remotes-practice && cd git-remotes-practice` — everything in this lab stays inside this one folder, so nothing outside it is ever at risk.

Project structure

git-remotes-practice/
  project/            (your working repository)
  fake-remote.git/    (a bare repo standing in for GitHub -- created by you)
  teammate-clone/      (a second clone, standing in for a collaborator)

Starter files

TODO: create this yourself with the setup commands below.

Requirements

• project/ is a real Git repository with an initial commit, pushed to fake-remote.git via a remote named origin.
• teammate-clone/ is a real clone of fake-remote.git that has pushed at least one change back.
• project/ has fetched and pulled the teammate's change.
• A non-fast-forward push rejection was reproduced and recovered from with git pull, not a force push or reset.

Commands to run

• Create the working repository and its first commit

  mkdir project && cd project && git init && echo "# Remote Practice" > README.md && git add README.md && git commit -m "Initial commit"

• Create a bare repository one level up to stand in for a real remote (GitHub, GitLab, etc.) -- entirely on your own machine, no account or network needed

  cd .. && git init --bare fake-remote.git

• Back in project/, confirm no remote is configured yet

  cd project && git remote -v

• Add the bare repo as a remote named origin (the conventional name)

  git remote add origin ../fake-remote.git

• Confirm origin is registered, for both fetch and push

  git remote -v

• Rename it, then rename it back -- this is exactly what you'd run to fix a mistyped remote name

  git remote rename origin upstream && git remote rename upstream origin

• Push and set the upstream tracking relationship in one step (only needed this first time)

  git push -u origin main

• Confirm the tracking relationship git push -u just set up

  git branch -vv

• Simulate a teammate: clone the same remote into a second folder

  cd .. && git clone fake-remote.git teammate-clone

• As the teammate, make a change and push it (a normal push -- no -u needed, clone set tracking up automatically)

  cd teammate-clone && echo "Added by teammate" >> README.md && git add README.md && git commit -m "Teammate: update README" && git push

• Back in your own project/, fetch: this downloads the teammate's commit but does NOT touch your files

  cd ../project && git fetch origin

• Confirm fetch alone changed nothing in your working files

  cat README.md

• Now pull, which fetches AND merges -- this is the step that actually updates your files

  git pull

• Confirm your file now has the teammate's change too

  cat README.md

• Set up a rejection on purpose: as the teammate, push another change first

  cd ../teammate-clone && echo "Second teammate change" >> README.md && git add README.md && git commit -m "Teammate: second update" && git push

• Meanwhile, without pulling first, make your own local commit in project/

  cd ../project && echo "Your own local change" >> README.md && git add README.md && git commit -m "Your own change"

• Try to push: Git REJECTS this (non-fast-forward) because origin/main now has a commit you don't have locally

  git push

• The safe recovery: pull first (fetches and merges the teammate's commit into yours), THEN push

  git pull && git push

Expected behavior

The first `git push -u origin main` succeeds and prints a line ending in something like "Branch 'main' set up to track 'origin/main'." After the teammate pushes, your `git fetch` prints an update to `origin/main` but `cat README.md` shows no change; `git pull` then updates it for real. The rejected push prints a line containing `[rejected]` and `(non-fast-forward)`, with a hint to "Integrate the remote changes ... before pushing again" -- that hint IS the recovery: `git pull` (which may open an editor for a merge commit message, exactly as in the previous lesson) followed by a normal `git push`, which then succeeds.

Verify it yourself

• git remote -v

  Expected: origin listed twice (fetch and push), pointing at ../fake-remote.git

• git log --oneline

  Expected: shows your initial commit plus both the teammate's commits and your own change, all combined

• git branch -vv

  Expected: shows main tracking origin/main, with no "ahead"/"behind" count remaining after the final push succeeds

Troubleshooting

• `fatal: 'origin' does not appear to be a git repository` (or similar) when pushing — Confirm `git remote -v` shows origin pointing at ../fake-remote.git, and that you're running the command from inside project/, not git-remotes-practice/ itself.
• `! [rejected] main -> main (non-fast-forward)` — This is expected at the step that deliberately reproduces it -- it means the remote has a commit you don't have locally yet. Run `git pull` to merge it in, then `git push` again. Never `git push --force` or `git reset --hard` to make a rejection like this "go away" -- that discards real work instead of integrating it.
• A real GitHub/GitLab push instead asks for a username/password or hangs waiting for authentication — This lab's local bare-repo remote never needs authentication, but a real hosted remote will use your OS credential manager, an SSH key, or a browser sign-in prompt -- never type a token directly into the remote URL; if a real push ever prompts unexpectedly, stop and confirm you're pushing to the repository you intend to before entering anything.

Extension challenge

Run `git log --oneline --graph --all` inside project/ after the final push and identify which commits came from you and which came from teammate-clone/ -- then run `git remote show origin` to see the full tracking-branch summary Git keeps for a configured remote.