Branching and Integration Lab

Planning allowance: 2–3 hours, included in Module 3. Start in the clean git-state-lab from the guided lab. Check git status before each phase. All branches here are unpublished. Do not run this exercise in a real project.

1. Rebase an unpublished branch without an accidental conflict

git switch -c feature-a
printf 'First local note\n' > feature.txt
git add feature.txt
git commit -m 'Add feature note'
printf 'Second local note\n' >> feature.txt
git add feature.txt
git commit -m 'Extend feature note'
git log --oneline -2
git switch main
printf 'Shared context\n' > context.txt
git add context.txt
git commit -m 'Add main context'
git switch feature-a
git rebase main
git log --oneline --graph --decorate --all

Record the feature commit IDs before and after. Their parentage changes, so the replayed commit IDs change; both note lines must remain and context.txt must exist. The edits deliberately use different files to isolate the history lesson. If rebase unexpectedly conflicts, inspect status and use git rebase --abort to return to the pre-rebase state before diagnosing the fixture. Rebase conflicts, when intentional, are resolved per replayed commit with git add and git rebase --continue.

Integrate the replayed branch:

git switch main
git merge --ff-only feature-a

This is a fast-forward; it does not create a two-parent merge commit. Explain why main is now an ancestor of the feature tip before integration.

2. Create an actual divergent conflict

A branch created from current main and edited alone can usually fast-forward. To require a conflict, both branches must change the same inherited line differently. Create the common baseline first:

printf 'Review: pending\n' > review.txt
git add review.txt
git commit -m 'Set common review baseline'
git switch -c feature-b
printf 'Review: explain restore limits\n' > review.txt
git add review.txt
git commit -m 'Require explanation of restore limits'
git switch main
printf 'Review: inspect restored contents\n' > review.txt
git add review.txt
git commit -m 'Require restored-content inspection'
git merge feature-b

The last command should return nonzero and report a content conflict. Inspect git status and review.txt; do not continue as though merge succeeded. Explain the two requirements rather than blindly choosing a side.

3. Abort, then resolve deliberately

git merge --abort
cat review.txt
git status --short
git merge feature-b

After abort, main's pre-merge line should be restored and status clean. The second merge should conflict again. The intended policy requires both content inspection and explanation of limits. Preserve a prediction of your resolution, then use your editor to make the entire file:

Review: inspect restored contents and explain restore limits

Save it with a final newline and verify:

git diff
git add review.txt
git diff --staged
git diff --cached --check
git commit -m 'Combine both review requirements'
cat review.txt
git rev-list --parents -n 1 HEAD
git log --oneline --graph --decorate --all
git branch -d feature-b

The final commit has two parent IDs after its own ID. No conflict markers remain; both requirements survive. --check catches whitespace/marker issues, not correctness of the policy. Read the content as well. If a commit editor opens during another workflow, save its message and exit using your editor's normal controls.

Fresh transfer and acceptance

Create another common-base text file with two independent requirements expressed as competing same-line edits. Predict whether integration is fast-forward, clean merge or conflict before running it. Explain the final requirement, graph and abort path. Require a rewritten unpublished history, a real conflict, an observed abort and a correct two-parent merge; a fast-forward alone cannot satisfy the conflict requirement.

Optional depth: interactive rebase to squash or drop commits belongs to a separate disposable branch after this core exercise. It is not an extra completion quota.