Checkpoint Lab — Version Control Foundations and Distributed Collaboration

1. Scenario and topology

You are modeling a tiny platform team. origin.git is the shared bare repository. Alice and Bob each have ordinary clones. The entire scenario stays on your local disk; no GitHub/GitLab account, SSH key, token, or internet connection is required.

flowchart LR
O[(origin.git
bare repository)] <--> A[Alice clone
working tree + repo]
O <--> B[Bob clone
working tree + repo]
A -. no direct live sync .- B

Success means you can explain each ref movement, not merely reach a clean status.

2. Preflight checks

git --version
# Run the next commands only in the new disposable lab parent.
pwd

Choose an empty parent directory. If a directory named git-foundations-checkpoint already contains anything you care about, stop and use a different name.

Git Bash, Bash, or zsh

mkdir git-foundations-checkpoint
cd git-foundations-checkpoint

PowerShell

New-Item -ItemType Directory git-foundations-checkpoint | Out-Null
Set-Location git-foundations-checkpoint

3. Create the bare origin with an explicit initial branch

git init --bare --initial-branch=trunk origin.git
git --git-dir=origin.git rev-parse --is-bare-repository
git --git-dir=origin.git symbolic-ref HEAD

true
refs/heads/trunk

The symbolic HEAD names the intended default branch even though no commit exists yet. The first successful push to trunk will create that branch ref.

4. Alice clones the empty origin and creates the first shared commit

git clone origin.git alice
cd alice
git config user.name "Alice Example"
git config user.email "alice@example.invalid"
git remote -v
git status --short --branch

The clone is a full local repository. The remote name origin is simply a configured shortcut to the source repository path.

Create content — Git Bash/Bash/zsh

printf "%s\n" "# Platform Delivery" "" "Service: checkout-api" > README.md

Create content — PowerShell

@("# Platform Delivery", "", "Service: checkout-api") | Set-Content -Encoding utf8 README.md

git status --short --branch
git add README.md
git diff --staged -- README.md
git commit -m "docs: add platform delivery readme"
git log --oneline --decorate --graph --all -5

Prediction 1 — before push: Alice's trunk names the new commit. The bare origin does not yet have that commit reachable from refs/heads/trunk.

git push -u origin trunk
git status --short --branch
git log --oneline --decorate --graph --all -5

Verify the prediction: after push, Alice's local origin/trunk and the bare repository's trunk refer to the pushed commit.

5. Bob clones after the first push

cd ..
git clone origin.git bob
cd bob
git config user.name "Bob Example"
git config user.email "bob@example.invalid"
git status --short --branch
git log --oneline --decorate --graph --all -5

Bob begins with the shared commit because he cloned after Alice pushed it. Bob's trunk is still a local ref in Bob's repository; it merely starts at the same commit as Bob's origin/trunk.

6. Alice independently advances history

cd ../alice

Git Bash/Bash/zsh

printf "%s\n" "Preflight: verify staging health" >> README.md

PowerShell

"Preflight: verify staging health" | Add-Content -Encoding utf8 README.md

git status --short
git diff -- README.md
git add README.md
git diff --staged -- README.md
git commit -m "docs: add staging preflight"
git push

Alice has now authored a second commit in her clone and published it to origin. Bob has not communicated with origin since cloning.

7. Prediction 2 — what will Bob's fetch change?

Before running anything, predict:

• Bob's local trunk will remain on the first commit after git fetch origin.
• Bob's remote-tracking ref origin/trunk will advance to Alice's second commit.
• Bob's working-tree files will not be rewritten merely by fetching.

Now observe before and after:

cd ../bob
git status --short --branch
git log --oneline --decorate --graph --all -6
git fetch origin
git status --short --branch
git log --oneline --decorate --graph --all -6

If the prediction was correct, the graph shows Bob's trunk behind origin/trunk by one commit, while the working tree still corresponds to Bob's current local commit.

8. Integrate only because a fast-forward is possible

Bob has no local commit that diverges from Alice's line, so moving his branch forward is sufficient:

git merge --ff-only origin/trunk
git status --short --branch
git log --oneline --decorate --graph --all -6

If --ff-only fails, stop and inspect the graph; do not remove the option just to make the command “work.” A failure means the history is not the simple case this checkpoint expects. Full merge/rebase decisions are later chapters.

9. Bob independently creates and pushes a commit

Git Bash/Bash/zsh

printf "%s\n" "Rollback owner: platform-team" > rollback.md

PowerShell

"Rollback owner: platform-team" | Set-Content -Encoding utf8 rollback.md

git status --short
git add rollback.md
git diff --staged -- rollback.md
git commit -m "docs: add rollback owner"
git log --oneline --decorate --graph --all -6
git push

Both clones have now created commits. Bob's commit is based on the fetched/fast-forwarded shared history, so his push is a straightforward update to the shared trunk.

10. Prove Alice's clone does not update itself

Return to Alice but do not fetch yet:

cd ../alice
git status --short --branch
git log --oneline --decorate --graph --all -6

Alice's repository still reflects the state from her last communication. Now fetch:

git fetch origin
git status --short --branch
git log --oneline --decorate --graph --all -6

Alice's origin/trunk should now point at Bob's commit while Alice's local trunk remains one commit behind. Complete the simple integration:

git merge --ff-only origin/trunk
git status --short --branch

This is the central checkpoint proof: a remote repository can advance without silently mutating another clone. Fetch updates Alice's knowledge; integration updates her current branch.

11. Inspect the shared repository directly

From the checkpoint parent directory, you can ask the bare repository which refs it has without entering a working tree:

cd ..
git --git-dir=origin.git show-ref
git --git-dir=origin.git log --oneline --decorate --graph --all -6

You should see the shared refs/heads/trunk at Bob's newest commit. Alice and Bob can each independently verify that their local trunk has been fast-forwarded to the same commit.

12. Verification checklist

• origin.git reports true for --is-bare-repository.
• Alice and Bob each have their own .git repository and ordinary working tree.
• Alice authored at least one commit and Bob authored at least one commit using only repository-local fake identities.
• Before Bob fetched Alice's second commit, Bob could not see it in his local refs/history.
• After fetch, origin/trunk advanced before Bob's local trunk did.
• Both integrations used git merge --ff-only, so the lab never hid divergence behind an automatic merge.
• Final Alice/Bob trunk refs and origin's trunk identify the same newest commit.

13. If the checkpoint does not match the expected graph

Do not reset or force-push. This is a disposable lab, but the learning goal is diagnosis. In the affected clone run:

git status --short --branch
git log --oneline --decorate --graph --all -10
git remote -v
git branch -vv

If --ff-only fails, your local branch likely contains a commit not present in the fetched line or you are on the wrong branch. Compare the graph and repeat the lab from a clean disposable parent if necessary; do not introduce rebase/force operations before their chapters.

14. Cleanup/restore

Because every repository in this checkpoint was created only for the lab, cleanup can remove the entire checkpoint parent. First verify the current path and contents.

Git Bash, Bash, or zsh

pwd
ls
cd ..
# Verify the name one final time, then remove only the disposable lab:
rm -rf git-foundations-checkpoint

PowerShell

Get-Location
Get-ChildItem
Set-Location ..
# Verify the name one final time, then remove only the disposable lab:
Remove-Item -Recurse -Force git-foundations-checkpoint

15. Knowledge check

16. What Chapter 01 adds to a production Git operating model

You now have the foundational control loop: identify the repository and current branch; distinguish working tree, staged state, commits, branches, and remote-tracking refs; commit locally; exchange state explicitly; and verify each transition. Production CI/CD and GitOps systems automate the same ideas at larger scale—they must identify exact commits, fetch the right refs, avoid guessing branch names, and record which source state produced an artifact or deployment.

17. Chapter checkpoint summary

Distributed Git is not complicated because “everything is remote.” It is powerful because repositories are independent. Each clone can create and inspect history locally. Collaboration happens when repositories exchange objects/ref updates. That independence explains both offline workflows and the need for deliberate synchronization policy.

Authoritative references

• git-clone
• git-fetch
• git-push
• git-remote
• git-branch
• git-status