Collaboration and Review Lab

Planning allowance: 2–3 hours inside Module 3. Use another new empty parent folder outside real repositories. All remotes below are local filesystem paths. This is a solo simulation unless another person actually participates; a bare repository does not provide a pull-request website.

1. Create a predictable remote and two clones

git init --bare -b main origin.git
git clone origin.git alice
cd alice
git config --local user.name 'Practice Alice'
git config --local user.email 'alice@example.invalid'
git config --local commit.gpgsign false
printf 'Purpose: inspect a restore\n' > README.md
git add README.md
git commit -m 'Set shared baseline'
git push -u origin main
cd ..
git clone origin.git bob
cd bob
git config --local user.name 'Practice Bob'
git config --local user.email 'bob@example.invalid'
git config --local commit.gpgsign false

The first empty-clone warning is expected. Specifying the bare repository's initial branch avoids depending on a machine's default branch name. Bob is cloned after main exists. Inspect git remote -v: it must refer to the local fixture, not a hosted project. Do not add a real network remote for this exercise.

2. Publish, fetch and inspect before integration

From Bob, switch to Alice's sibling directory:

cd ../alice
git switch -c feature/restore-note
printf 'Purpose: inspect a restore and explain limits\n' > README.md
git add README.md
git commit -m 'Explain restore limits'
git push -u origin feature/restore-note
cd ../bob
git rev-parse HEAD
cat README.md
git fetch origin
git rev-parse HEAD
cat README.md
git show origin/feature/restore-note:README.md
git diff main..origin/feature/restore-note -- README.md

Predict before fetching: Bob's checked-out main and working file stay unchanged; the new remote-tracking branch becomes inspectable. Fetch downloads objects and updates relevant refs, but does not integrate this feature into Bob's current branch. The remote-tracking reference is local; the other clone cannot update it without Bob communicating with origin.

3. Review and revise locally

Write a short review in your private notes: purpose, exact diff, content check and one limitation. Ask for a visible clarification: the README should say this is a same-device restore, not a general disaster-recovery guarantee. Label your note “solo review simulation”; do not invent feedback from another person.

git switch -c review/clarify-scope origin/feature/restore-note
printf 'Purpose: inspect a same-device restore and explain limits\n' > README.md
git add README.md
git commit -m 'Clarify restore scope after review'
git push -u origin review/clarify-scope
git branch -vv
git switch main
git merge --ff-only origin/feature/restore-note
git merge --ff-only review/clarify-scope
git push origin main

Explain the upstream of the review branch after push -u; do not infer it from the local branch name alone. Confirm the final file includes the clarification. In a real hosted workflow, write the same scope/evidence/limits in the pull request; opening or posting one is not required here.

4. Observe a stale push rejection

Alice's main has not integrated Bob's work. Create a different-file local commit from that stale main:

cd ../alice
git switch main
printf 'Keep review evidence\n' > handoff.txt
git add handoff.txt
git commit -m 'Add local handoff note'
git push origin main

Expect rejection because origin/main is not an ancestor of Alice's divergent main. Do not force-push to remove Bob's work. Inspect then integrate explicitly:

git fetch origin
git log --oneline --graph --decorate --all -10
git merge --no-edit origin/main
cat README.md
cat handoff.txt
git push origin main
cd ../bob
git pull --ff-only origin main
git log --oneline --graph --decorate --all -8

The distinct-file merge preserves both the clarified README and handoff. Bob's final pull can fast-forward because Bob added no further local commits. --ff-only would refuse divergence; it does not silently select rebase or overwrite work. The explicit local pushes here share only disposable fixtures.

Acceptance and transfer

Preserve pre/post-fetch HEAD and file evidence, remote-tracking content, upstream inspection, labeled review and revision, rejected push output, integration graph and final contents in both clones. Then use a new topic branch and different text requirement to explain which clone remains stale until fetch and what explicit integration changes.

Missing independent human feedback stays labeled missing; local mechanics can still be demonstrated. Do not repeat this entire lab merely to satisfy a second “integrated expansion” checklist.