Collaborate, inspect incoming work and resolve a real conflict

Practice transport without publishing externally

Run the following from script-project. The sibling destinations must be new. A bare repository holds Git history without a normal checked-out project tree. It can serve as a local remote for this exercise:

git init --bare ../team.git
git remote add origin ../team.git
git push -u origin main
git clone --branch main ../team.git ../peer

The remote name origin is a convention, not a trusted authority. A real remote may have another name or URL. Inspect git remote -v before pushing and ensure that the destination and repository visibility are authorized. These commands publish only to a local path in the isolated lab.

From the peer directory, run the tests. The repaired behavior should pass independently. This clone receives committed files, not your excluded scratch note or an unstaged repair. If the original directory passed tests only because of an uncommitted change, the clone reveals that mismatch.

Make a peer documentation change

In peer, set a local fictional identity, add one line to README saying the peer confirmed the fixed boundary, and commit only README. Then push main to the local remote. Return to script-project and inspect:

git fetch origin
git log --oneline main..origin/main
git diff main..origin/main -- README.md
git merge --ff-only origin/main

Fetching updates remote-tracking information; it does not itself change your current working commit to the peer's commit. Inspect before integrating. The explicit fast-forward works here because the exercise has no local divergence. A real collaboration may need a merge decision, review approvals or a pull request rather than direct pushes to main.

GitHub provides hosting and collaboration features around Git. A pull request communicates a proposed change and its evidence; it is not automatic proof of quality. Configure branch restrictions, required checks and review permissions according to the project, and verify them on the actual service. The offline lab does not claim to have enabled those protections.

Create a conflict over collection scope

The next exercise changes a documentation fixture, scope.txt, not the classifier. Create a branch named docs/collection-scope, add scope=visible-txt as its sole line and commit it. Switch to main and fast-forward that branch. Then create docs/hidden-scope, change the line to scope=visible-and-hidden-txt and commit.

Switch back to main, change the same line to scope=visible-top-level-txt, and commit. These branches now contain different edits to the same base line. Run git merge docs/hidden-scope. It should stop with a conflict; status reports an unmerged path.

Inspect the file in your editor and the proposed histories. Conflict markers describe competing text, not which requirement is correct. Choosing “ours” or “theirs” mechanically can discard a needed clarification or approve unreviewed scope. Our exercise owner has approved visible, nonrecursive collection only, so the resolved file must contain exactly:

scope=visible-top-level-txt

Stage that reviewed resolution, inspect the cached diff and commit the merge with a message explaining the scope decision. Run the classifier tests again. They should pass because the scope document does not change classifier behavior, but they do not validate a future file collector's scope. That separate requirement needs its own collector tests.

Exercise: when should a merge be aborted?

Suppose there is no owner decision on hidden files and they may contain credentials. What should the reviewer do? What if the conflict also includes uncommitted work made before the merge?

Worked reasoning

Pause the scope expansion and obtain an authorized decision rather than picking a side to remove the conflict. In a clean isolated lab, git merge –abort can return from the in-progress merge. In a dirty real tree, do not assume every prior edit is perfectly reconstructible: preserve and inspect the existing work before beginning recovery. A resolved textual conflict is not proof that the resulting behavior meets its requirement.

Worked laboratory solution

Compare your reasoning with the worked solution

The missing test is exactly 10, expected OK. It fails on the old inclusive comparison and passes on the strict comparison. Keep 9=Alert and 11=OK as neighboring checks. The unrelated configuration rename expands risk and should be removed from this change or reviewed as a separate justified task. The ideal diff includes the boundary fix, regression test and any necessary concise documentation. A passing suite without the exact-boundary test would not demonstrate the reported bug was addressed.

Official reference for further study

Download the course workbook and practice materials