Introduction
The garden’s next guide update involves two correct facts on the same line. Your prepared commit moves visitors to the south entrance and updates the visitor desk phone. A teammate’s published commit changes opening hours and the step-free route. The final guide needs both sets of information.
This lab starts with its own independent repositories; it needs no files from the previous VM. You will see a real content conflict, practice canceling an unfinished merge, combine the correct fields and deliver the result to a new receiving clone.
Complete the previous guided lab, or already understand remote names, fetching, merging, pushing and cloning. Basic terminal navigation, commits and diffs are prerequisites. The 45-minute duration is an author estimate.
Read and Safely Restart a Conflict
In this step, compare the two contributions, see why automatic merging stops, and practice a safe return to the original local state.
Open Terminal and enter this lab’s independently prepared repository:
cd /home/labex/project/guide-team/editor
Set an identity only for this repository. --local avoids changing global settings; quotes keep the name together. These synthetic values are examples, not required personal details:
git config --local user.name "Guide Editor"
git config --local user.email "guide@example.com"
Read the prepared local guide, then fetch the teammate’s update:
cat guide.txt
git fetch origin
Read the teammate’s version. revision:path selects an actual committed file, and --no-pager prints it directly:
git --no-pager show origin/main:guide.txt
Your version says South entrance with 09:00-17:00; the teammate’s says North entrance with 10:00-18:00. The business decisions are independent: use your south entrance and the teammate’s new hours. Preserve the last-entry sentence. Keep your visitor desk phone and the teammate’s riverside ramp from their other pages.
Start the merge. --no-edit avoids an editor if a merge completes automatically. Here it is expected to return a nonzero status and stop for a content conflict. Run it on its own, then continue:
git merge --no-edit origin/main
Expect CONFLICT (content): Merge conflict in guide.txt and Automatic merge failed; fix conflicts and then commit the result. Git has not made a new commit.
Read the short status and the conflicted file:
git status --short
cat guide.txt
UU guide.txt means the file is unmerged. In the file, <<<<<<< HEAD starts your version, ======= separates the alternatives, and >>>>>>> origin/main ends the teammate’s version. These markers describe a disagreement; deleting only the markers would leave contradictory lines. The route page may already be staged as M access.txt because Git merged that independent change successfully.
Before resolving, practice recovery. git merge --abort cancels only the unfinished merge, returning tracked files and the index to their pre-merge state. This scene began clean; in ordinary work, commit or set aside unrelated edits before starting a merge.
git merge --abort
git status --short
No changes should appear. Read the guide again: the original south entrance and old hours are back.
cat guide.txt
Now restart the same merge. The conflict and nonzero status are expected again. Leave this second conflict open for the next step:
git merge --no-edit origin/main
git status --short
The checkpoint expects an active unresolved guide.txt conflict. If you mistype a path, use pwd and ls, then return with the full cd command above. Do not delete .git or reset the VM to recover a normal navigation error.
Resolve the Information and Complete the Merge
In this step, turn the conflict into one usable guide line, while keeping the pages Git already merged.
Stay in Terminal, in /home/labex/project/guide-team/editor, with the conflict from the previous step open. You need South entrance from your contribution and 10:00-18:00 from your teammate. Choosing the whole file from either side would lose one approved change.
The following command replaces only guide.txt with its complete three-line result. > redirects output into that file, replacing its contents. <<'GUIDE' is a here-document: the following lines are literal input until a line containing only GUIDE. Copy the entire block, including its final marker. Quoting the marker prevents shell expansion within the text. No programming is required.
cat > guide.txt <<'GUIDE'
RIVERLIGHT GARDEN
Gate: South entrance; Hours: 10:00-18:00
Last entry is 30 minutes before closing.
GUIDE
Read all three files before staging. The last-entry sentence must remain; access.txt must contain the riverside ramp; contacts.txt must contain your updated phone.
cat guide.txt
cat access.txt
cat contacts.txt
Expected additional-page contents:
Step-free route: Use the riverside ramp
Visitor desk: 010-555-0120
git add records the resolved file in the index and marks its conflict resolved. It does not itself create a commit:
git add guide.txt
Review what the merge will add relative to your original local commit. diff --cached compares the staged result with HEAD; --no-pager keeps the output in this terminal:
git --no-pager diff --cached
Expect the hours change in guide.txt and the ramp change in access.txt. Your south entrance and visitor phone were already in your local parent, so they need not appear as newly added lines in this comparison. Check the final files as well as this diff.
If you see a spelling error, repeat the complete guide block with the correction and run git add guide.txt again. If you want to abandon the unfinished attempt entirely, use the previous step’s git merge --abort, restart the merge, and repeat the resolution. Do not use abort after completing the commit.
Finish the merge with a descriptive message. -m supplies the message directly rather than opening an editor; other meaningful wording is accepted:
git commit -m "Combine gate and opening hours"
Inspect its two lines of ancestry and clean working tree:
git --no-pager log --oneline --graph --all --decorate
git status --short
No status output is expected. Both original contribution messages must remain below the new merge. The checkpoint requires that history and complete correct files, not merely the absence of conflict markers.
Publish and Receive the Complete Guide
In this step, deliver the merged revision to the shared repository and read it from a new receiving copy. A local merge alone has not delivered anything to another copy.
Stay in Terminal, in /home/labex/project/guide-team/editor. push origin main sends the local main history to the repository named origin. This time the shared contribution is an ancestor of your merge, so the push can advance shared main without removing it.
git push origin main
Expect main -> main without a rejection. If it is rejected, fetch and inspect the graph again; do not add a force option. This prepared scene has no background contributor, but a real team may publish new work at any time.
Now move to the directory containing both repositories:
cd /home/labex/project/guide-team
git clone creates a new repository and working files from a source. Here shared.git is the existing local source path and received-guide is the new destination directory. The receiving copy must start from the shared repository, so it will reveal whether the merge was actually delivered.
git clone shared.git received-guide
Expect Cloning into 'received-guide'... and done.. If you already cloned while experimenting, keep that copy: enter received-guide and use the previously taught git fetch origin followed by git merge --no-edit origin/main to bring it forward. Do not delete the original editor to retry a clone.
Enter the receiving copy:
cd received-guide
Read each actual file. cat prints a file without changing it:
cat guide.txt
cat access.txt
cat contacts.txt
Compare the information with the combined business requirements from the previous step. All three files must be complete, including unchanged lines. A successful clone message alone cannot prove the information is correct.
Finally, read the receiving history. --oneline shortens each commit, --graph draws its parent links, and --decorate labels branch pointers. --no-pager prints directly instead of opening a scrollable viewer.
git --no-pager log --oneline --graph --decorate
The top merge has two lines of ancestry, including both original contribution messages and the opening commit. Your exact commit IDs vary. Check that no content was lost and that the receiving copy is on main with a clean tracked working tree:
git status --short
No output means there are no staged, unstaged or untracked changes. You have delivered a usable file collection through actual Git repositories, all running on this one training machine.
Summary
You read both sides of a real conflict, used git merge --abort to recover safely, then composed the correct fields instead of choosing an entire side. You retained the automatically merged route, your visitor phone and the unchanged guide sentence.
The published merge and independent receiving clone now contain the complete guide, with both original contributions preserved. The challenge changes the handbook and reverses which contributor has each correct field.
