P-2.4 Working With Other People on Code

Work through these

• Working on a separate branch, and why that is the default habit

  A branch is a movable name for a line of commits, so starting one costs nothing and keeps unfinished work away from the version everyone else is using. Nearly every team convention is built on this one idea.

  Pro Git (2nd edition) · Reference

• Merging, and reading what a merge actually did

  Bringing two lines of work together produces a commit with two parents, and being able to read that in the history is how you reconstruct what happened later.

• Resolving a conflict by understanding both sides

  A conflict marks the places where two people changed the same lines and the tool will not choose for you. Reading both versions and deciding deliberately is the work; picking one at random is how correct code disappears.

• Remotes: pushing, pulling, and what happens when histories diverge

  Your copy and the shared copy are separate repositories that exchange commits, which is why a push can be refused. Understanding divergence removes most of the fear around that refusal.

• Opening a change for review, and reviewing somebody else's

  A review is a conversation about a proposed change before it becomes part of the shared history. Being useful in one means reading for correctness first and for taste a long way second.

  GitHub: Git Guides · Tutorial