Introduction
Riverlight Garden needs a correct visitor guide. Your prepared local commit moves the entrance and updates the visitor phone number. A teammate has already published a new step-free route. Visitors need all three corrections.
You will fetch the teammate’s work, merge the independent changes and publish the result. A new receiving clone will give you the actual delivered files. The shared repository and both copies are local directories on one training machine; this is real Git collaboration without a hosted service, server setup or account.
You should already recognize commits, a branch, git add, git commit and a basic diff. Remote names, fetching, merging, pushing and cloning are explained here. The 35-minute duration is an author estimate including reading and ordinary errors.
Discover the Teammate’s Update
In this step, find out why your prepared local update cannot yet be delivered, then obtain the teammate’s revision without changing your files.
Open Terminal. Start in the prepared editor repository:
cd /home/labex/project/guide-team/editor
cd changes this terminal’s working directory. If a path is mistyped, use pwd to print your current directory and ls to list it, then repeat the full cd command above. These ordinary navigation errors do not require a new VM.
A new merge commit will need an author identity. --local stores these settings only in this repository. The quoted text is one value even when it contains spaces; the sample email is synthetic. You may choose your own name and email.
git config --local user.name "Guide Editor"
git config --local user.email "guide@example.com"
Your existing local commit is already complete. Read its visitor information:
cat guide.txt
cat contacts.txt
You should see South entrance and visitor desk 010-555-0120. Keep the last-entry sentence in the guide. The separate route file still says Use the north ramp:
cat access.txt
git status --short gives a compact list of changed files. No output here means the prepared contribution is committed and the working tree is clean:
git status --short
A remote is a named connection to another repository. origin is this connection’s name, not a special server. -v shows its fetch and push addresses:
git remote -v
Both addresses point to /home/labex/project/guide-team/shared.git. This is a bare repository: it stores shared history without an editable working copy. Do not edit its internal files.
Try delivering your branch. push sends commits; main names the branch to update at origin. This first push is expected to fail with a nonzero exit status. Run it on its own and continue after the rejection:
git push origin main
Look for [rejected], main -> main and (fetch first). The shared branch contains work your current history does not contain, so Git refuses to replace it. This is a non-fast-forward update: the existing shared tip is not an ancestor of the proposed tip. Force-pushing would discard the teammate’s contribution from the branch and violate this task.
fetch downloads remote commits and updates a local remote-tracking pointer, origin/main. It does not merge them into your own main or rewrite your working files:
git fetch origin
Compare the histories. --oneline shows one short line per commit; --graph draws parent connections; --all includes both local and remote-tracking branches; --decorate adds their labels. --no-pager prints directly; if you open a pager while experimenting, press q to leave it.
git --no-pager log --oneline --graph --all --decorate
Find Move the gate and update the visitor desk on HEAD -> main and Update the step-free route on origin/main. Both descend from Open the garden guide. HEAD names the currently checked-out commit. The two contributions differ; neither is a substitute for the other.
Read the teammate’s route directly from its snapshot. show accepts a revision:path expression, so origin/main:access.txt means that file in the fetched revision:
git --no-pager show origin/main:access.txt
It says Use the riverside ramp. Your working route still says Use the north ramp. This difference proves that fetching made the new history available while leaving your working tree alone. The first checkpoint accepts that fetched revision with your original local commit still intact.
Combine the Independent Contributions
In this step, combine the two histories into one revision containing the south entrance, the updated visitor phone number and the riverside ramp.
Stay in Terminal, in /home/labex/project/guide-team/editor. A merge combines histories. Because these changes touch different files, Git can combine their text automatically. --no-edit accepts Git’s generated merge message and avoids opening an editor:
git merge --no-edit origin/main
Expect a successful merge summary, usually Merge made by the 'ort' strategy.. Git creates a merge commit with two parents: your original commit and the teammate’s original commit. Neither contribution is rewritten.
Read the real combined files:
cat guide.txt
cat access.txt
cat contacts.txt
The guide must retain South entrance, 09:00-17:00 and the last-entry sentence; the route must say Use the riverside ramp; the phone must remain 010-555-0120. Independent changes combined cleanly, but you still need to judge their meaning.
Review the resulting history:
git --no-pager log --oneline --graph --all --decorate
The merge at HEAD -> main joins both contribution lines. origin/main still labels the previously fetched teammate commit until you push. This is normal: merging changed local main, not shared main.
Check the working state:
git status --short
No output is expected. If a different experiment left a merge in progress, git merge --abort cancels that unfinished merge and restores the pre-merge state; run it only while a merge is in progress, then repeat the merge command. It does not cancel an already completed commit. The checkpoint requires one combined merge commit with both original parents and all three complete files.
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 handled a real push rejection, fetched a teammate’s commit without overwriting your own files, merged two independent contributions and delivered the complete guide through a shared repository. A real receiving clone contained the combined guide, step-free route and visitor contact.
The original commits remain in history. Next, practice a merge where Git needs your judgment because both people changed the same line.
