Team & hand-in

The shared-repository workflow

Two people, one origin, one rule with two halves:

What happens when you forget to pull and push anyway? Git refuses, politely:

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'https://github.com/username/iot-team-repo.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. ... You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.

Not an error in your work, just Git protecting your partner's: the remote has commits you have not seen. The fix is the hint: git pull, let Git merge, then git push. You will trigger this on purpose below.

Pair exercise, part 1: parallel work that merges cleanly

One partner (call them A) creates a fresh private repository iot-team-repo on GitHub, this time with "Add a README" ticked (the clone-first path), and invites partner B as a collaborator. Then both:

> git clone https://github.com/username-of-A/iot-team-repo.git
> cd iot-team-repo

1. Work on different files

   A creates about-a.md with two lines about themselves; B creates about-b.md. Each runs the cycle: status, add, commit -m.

2. A pushes, B pushes second

   A: git push, succeeds. B: git push, rejected with the fetch-first message above. Read it together; this is the workflow's most common moment.

3. B pulls, then pushes

   > git pull      # Git merges A's commit with yours; accept the proposed merge message
   > git push      # now succeeds

   Different files, so Git merged without questions. Both partners git pull and both now have both files. Check git log --oneline: both names, one shared history.

Pair exercise, part 2: a conflict on purpose

Now collide. Both partners open README.md, and on the same first line each writes a different team name. Each commits locally. A pushes first; B pulls and gets:

Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

Git changed nothing behind your back. It edited README.md to show both versions and paused, waiting for a human decision:

<<<<<<< HEAD
# Team Photon
=======
# Team Quantum
>>>>>>> a1b2c3d (A's commit message)

Read the anatomy: between <<<<<<< HEAD and ======= is your version; between ======= and >>>>>>> is the incoming one. The four-step resolution, the same every time:

1. Open the file

   In your editor. Find the conflict markers; git status lists every conflicted file, here just one.

2. Decide the final text

   Keep yours, keep theirs, or write a combination (perhaps the actual team name you now agree on). Delete the three marker lines; the file must read as if the conflict never happened.

3. Stage the resolution

   git add README.md, your statement that this file is settled.

4. Commit and push

   git commit -m "Resolve team name conflict", then git push. A pulls, and the pair agrees again.

A first branch

One taste of the sticky-note idea, because Assignment 1 and later labs will suggest it for experiments:

> git switch -c experiment     # create the branch and move onto it
>                              # ... edit, add, commit as usual: main is untouched ...
> git switch main              # step back to main: your experiment vanishes from the folder
> git merge experiment         # bring the experiment's commits into main
> git branch -d experiment     # delete the label; the commits stay in history

Watch the working directory change as you switch: that is the branch pointer moving, exactly as the diagram promised. If the merge ever conflicts, you already know the four steps. Deeper branching (shared feature branches, pull requests) waits until the project needs it; the interactive playground Learn Git Branching is the best place to build intuition meanwhile.

What to hand in

Week 1's evidence is mostly already on GitHub, which is the point. Assemble the rest in a folder and upload to Omnivox:

Like every week, this counts as completion of in-class work. Next week's Assignment 1 repeats this shape, graded, with a documented README at its centre.

Exit ticket

Answer without looking at the hub; write the answers at the end of config.txt if the teacher asks for them.

1. Name the four areas and the command that moves work between each pair.
2. Your push was rejected with "fetch first". What happened, and what do you type?
3. In a conflict block, which version sits above ======= and which below?
4. What single habit prevents most shared-repository problems?
5. Why does the course care about your commit history, in one sentence?

Homework and next week