Final assignment

After Module 5
about 3 hr

What you will be able to do

Show that you can use Git on a team from start to end. You work in one practice project, with one teammate, and you keep evidence of each step.

Before you startWhat to know and to have readyAbout 150 minutes

What you need to know

You completed Modules 1 to 5. Each part below names the lessons that it uses.

What you need on your computer

The labs repository in ~/projects/nextia-learning-labs. If you do not have it, clone it as in Pull-request sequence: Set up the practice lab. To get the newest version, run git -C nextia-learning-labs pull in ~/projects.
Git, with your name and email address, from Set up Git: Step 2: tell Git who you are.
The practice state final. You make it in Set up. You can do the assignment in more than one session. Your work stays in ~/projects/c14-lab until you run the setup script again.
You do not need an account on a website. Pull requests are simulated, as in Pull-request sequence: The simulation in this lesson.

The situation

You are Amira. You and Sam keep the help desk notes, and the help desk uses version 1.0. Three things need your attention:

A note to update. Ticket 103 needs its next action.
A shared mistake. One of Sam’s pushed commits removed a contact that the help desk still needs.
A bug in the release. Version 1.0 has the wrong extension for the network team. The fix must reach the help desk without the unfinished export work that is on main.

Set up

Make the practice repositories:

cd ~/projects
sh nextia-learning-labs/C14/setup.sh final --reset

Ready: /Users/amira/projects/c14-lab
  ticket-notes     your clone
  sam-notes        Sam's clone
  team-remote.git  the shared remote
Next: cd c14-lab/ticket-notes
To start this scenario again: sh nextia-learning-labs/C14/setup.sh final --reset

Move into your clone, and look at the history:

cd c14-lab/ticket-notes
git log --oneline --graph --all

* 0df72be (HEAD -> main, origin/main, origin/HEAD) Add ticket 105
* 0cc9f00 Remove old contacts
* 3cf73f7 Start the ticket export (not finished)
* 465d7ea (tag: v1.0.0, origin/release/1.0) Add escalation rules
* f330fdc Add ticket 104
* e058b3f Add ticket 103

The hashes match, because the script made these commits. Your own commits get different hashes.

Make the evidence file. It is in c14-lab, outside the repository, so that you do not commit it by accident:
Terminal window
```
touch ../evidence.md
```

The start state:

Reference	Points to	Notes
`main`	`0df72be`	Your clone. Sam pushed one more commit that you have not fetched yet.
`release/1.0` and tag `v1.0.0`	`465d7ea`	What the help desk uses. The network team extension `4410` is wrong. The correct value is `4401`.
`3cf73f7`	on `main`	The unfinished export work. It must not go into a release.

Rules for every part

Make every change on a branch. Merge it through a simulated pull request: a description file, a review, the check, then a merge with git merge --no-ff.
Write each pull request description in a file in c14-lab, for example ../pr-1.md. Use the shape from Module 3: Source → target, Problem, Change, How I checked.
Run sh check.sh before every merge. Do not merge when it shows FAIL.
Do not force a push, and do not rewrite commits that are on the remote.
After each part, copy the outputs that the part asks for into evidence.md.

Part 1: update a ticket through a pull request

Uses Modules 1 to 4: Track a first change, Pull-request sequence, Read and review diffs and Conflicts step by step.

On main, make a branch called ticket-103-next-step.
Add this text to the end of the Ticket 103 line: Next: check the network switch.
Commit with a clear message, and push the branch with -u.
Write ../pr-1.md. Source → target: ticket-103-next-step → main.
Review as Sam. In ../sam-notes, fetch, then read the diff of the pull request with three dots. Add one review comment to pr-1.md, under the heading Review.
Before you merge, update your branch with the newest main. In ticket-notes, fetch, then merge origin/main into ticket-103-next-step. A conflict stops the merge.
Read both sides, and the commit messages, before you edit. The resolved line must keep Sam’s fact and your next action, in an order that makes sense.
Run git diff --check and sh check.sh. Then complete the merge, and push the branch.
Switch to main, pull, and merge the branch with git merge --no-ff. Run the check, then push main.
Delete the branch, locally and on the remote.

Evidence for part 1:

pr-1.md, with the review comment.
The conflict: the output of git status --short while the merge was stopped, and the final Ticket 103 line.
git log --oneline --graph -6 on main after step 9.
git show --stat for your own commit from step 3. It must change only tickets.txt.

Part 2: undo a shared mistake

Uses Undo safely and Recover work.

Do this part before part 3. The fix in part 3 changes the line next to the removed contact. If the contact is still missing, the cherry-pick in part 3 stops with a conflict.

Find the commit that removed the Accounts team. Use git log --oneline -- contacts.txt, then git show on the commit that you suspect.
Make a branch called restore-accounts-contact, and undo that commit with git revert.
Check that Sam’s later commits are still there: ticket 105, and Sam’s change to Ticket 103.
Write ../pr-2.md (source → target: restore-accounts-contact → main), then merge and push as in part 1.
Practise a recovery in a disposable clone. In c14-lab, run git clone team-remote.git scratch. In scratch, run git reset --hard HEAD~2. Then find the lost commit with git reflog, and bring main back to it. Delete scratch when you finish.

Evidence for part 2:

The output of git show --stat for the revert commit, with its message This reverts commit ….
Two sentences: why you used revert and not reset on main.
From step 5: the git reflog lines that you used, and git log --oneline -3 after the recovery.

Part 3: repair the release

Uses Release branches and tags, Cherry-pick a fix and Keep histories consistent.

Fix the bug on main first. Make a branch called fix-network-extension, change 4410 to 4401 in contacts.txt, and commit.
Write ../pr-3.md (source → target: fix-network-extension → main), then merge and push.
Find the hash of the fix commit. Use the commit from step 1, not the merge commit from step 2.
Make a local release/1.0 with git switch release/1.0. Then make hotfix/1.0.1 from it.
Copy the fix with git cherry-pick -x. Run sh check.sh, and push hotfix/1.0.1 with -u.
Write ../pr-4.md (source → target: hotfix/1.0.1 → release/1.0). Under How I checked, show that the release gets only the fix.
Merge hotfix/1.0.1 into release/1.0 with --no-ff. Make the annotated tag v1.0.1 on the result.
Push release/1.0 and the tag.

Evidence for part 3:

git log -1 --format=%B for the cherry-picked commit. The message must include (cherry picked from commit …).
git diff --stat v1.0.0 v1.0.1. Only contacts.txt changes.
git show v1.0.1:export.txt. Git must show fatal: path 'export.txt' does not exist in 'v1.0.1'.
git log --oneline --cherry-mark main...release/1.0. Your fix shows twice, with = in front of each copy.
One sentence: does main need a merge from release/1.0 now? Why, or why not?

Check your evidence

For each required item, choose the result that matches your evidence. The course is complete when all four items are demonstrated. If an item is not, fix that part and check it again. You can do this as many times as you need.

Required item	Demonstrated	Partially demonstrated	Not yet demonstrated
Clear commits and a readable diff	Each commit has one purpose and an instruction-style message. `git show --stat` shows only the files for that purpose.	The commits are correct, but one mixes two changes or has an unclear message.	Commits mix unrelated changes, or contain files that must stay out, such as a log file or a secret.
Correct branch and pull request sequence	Each change was on its own branch. Each PR file names the correct source and target. The check passed before each merge.	One PR has the wrong target in its file, but the merge went to the correct branch.	A change went straight to `main` or `release/1.0`, or a merge happened while the check showed `FAIL`.
Resolved conflict	The final line keeps both Sam’s fact and your next action. No conflict markers remain, and the check passes.	Both facts are kept, but the line is hard to read, or you did not run the check.	One side is lost, or markers such as `<<<<<<<` are in a commit.
Safe recovery	The faulty commit is reverted on `main`, and Sam’s later commits are still there. You used the reflog to restore the scratch clone. Your release has the fix and no export work.	The undo is correct, but your explanation of revert and reset is missing or wrong.	You used `reset` or a force push on a shared branch, or Sam’s later work is missing.

Any item with a destructive action on shared history is not yet demonstrated, even if the rest of the work is correct.

Show model evidence for the hardest steps

The resolved Ticket 103 line in part 1:

Ticket 103: shared drive is slow. Moved the user to the new server. Slow again on Monday. Next: check the network switch.

Sam’s fact comes first, because it happened first. Your next action follows from it.

Why revert, not reset (part 2): Sam’s faulty commit is on the remote, and later commits are on top of it. git reset would move main back and remove those later commits, and the remote would refuse the push. git revert adds a new commit that undoes only the faulty change, so everyone’s history stays the same.

Part 3, the duplicate fix after the release is repaired:

+ 68588d0 Merge branch 'fix-network-extension'
+ 932e885 Merge branch 'hotfix/1.0.1' into release/1.0
= dad18dd Fix the network team extension
= 0bdbe24 Fix the network team extension

Your hashes are different. The two = lines are the same change with two hashes. main already has the fix, because you fixed it there first. A merge from release/1.0 is not needed for this fix. Many teams still merge the release back into main, so that git log main..release/1.0 stays empty before the next release.

Common mistake

The cherry-pick says the commit is a merge

Symptom:

error: commit 68588d0965fe888faf1f203a298a52e85f52f227 is a merge but no -m option was given.
fatal: cherry-pick failed

Cause: you gave the hash of the merge commit from part 3, step 2. A merge commit has two parents, so Git does not know which change to copy.

Fix: run git log --oneline main -4. Use the hash of the commit with your fix message, not the Merge branch commit, and run the cherry-pick again.

Common mistake

The cherry-pick stops with a conflict in contacts.txt

Symptom: CONFLICT (content): Merge conflict in contacts.txt. The file shows Accounts team on one side only.

Cause: you did part 3 before part 2. Your fix was made when the Accounts team line was missing. The release still has that line, next to the line that you changed.

Fix: run git cherry-pick --abort. Do part 2, then make the fix again on main, and cherry-pick the new fix commit.

Optional stretch work

These tasks are not required for completion.

Merge release/1.0 back into main through a pull request. Then check that git log --oneline main..release/1.0 is empty.
Do parts 1 and 3 again with a private repository on GitHub, and real pull requests. Compare each step with the simulation.

Recap

In this course, you learned to:

track and inspect changes, so that each commit is one clear step;
work through branches and pull requests, and review a diff before you approve it;
resolve a conflict, and undo or recover work without losing a teammate’s changes;
release with a branch and a tag, and move one fix to the release with a traceable cherry-pick.