Same-Branch Collaboration

Every chapter so far assumed you're the only person touching the repository. The moment a second person commits to the same branch, a few new situations become possible — none of them are mistakes, all of them are completely normal, and this final chapter of Course 1 walks through exactly what each one looks like and how to handle it calmly.

The Core Rule: Git Won't Let You Silently Overwrite Someone Else's Work

This is the single most important thing to understand before working with anyone else: git is specifically designed to reject a push that would erase commits it doesn't recognise. You cannot accidentally destroy a collaborator's work just by pushing — git stops you and asks you to reconcile first.

Scenario A: Someone Else Pushed Before You

This is not an error in the sense of something being broken — it's git correctly noticing that the remote has a commit (your collaborator's footer fix) that your local branch doesn't have. The fix is simply to pull first:

Because you and your collaborator edited different files (header.css vs footer.css), git merges them automatically with no conflict at all — this is the most common outcome by far in day-to-day collaboration.

Scenario B: You Both Edited the Same Lines — a Real Conflict

Sometimes the overlap is real: you and your collaborator both changed the exact same line of the exact same file. Git can't guess which version is correct, so it pauses and asks you to decide.

Opening index.html shows git's conflict markers directly in the file:

Everything between <<<<<<< HEAD and ======= is your version; everything between ======= and >>>>>>> is theirs. Resolving means manually editing the file to keep whichever version is correct (or a combination of both) and removing the marker lines entirely.

Preventing Most Conflicts Before They Happen

• Pull frequently — at the start of each session, and before pushing, not just when forced to.
• Use branches for anything non-trivial (Chapter 4) — working in your own branch and merging via a reviewed PR (Chapter 7) catches most overlaps before they become a tense same-branch conflict.
• Communicate about who's touching what — a quick "I'm working on the header right now" message prevents most same-line conflicts before git ever needs to flag one.
• Commit and push in smaller, more frequent chunks — large, infrequent commits diverge further from the shared branch and produce bigger, harder conflicts when they finally meet.