Git for teams

How a merge works

Two editors mark up copies of the same draft. To combine them, you don't compare one copy with the other. You compare each with the original. Git does the same. It finds the merge base: the last commit both branches share. Then it works out two sets of changes:

• base → ours (your branch),
• base → theirs (the branch being merged).

Where only one side changed a region, take that change. Where both made the same change, take it once. Where both changed the same region differently, that's a conflict: Git can't know which you meant, so it writes both with markers:

<<<<<<< ours
TIMEOUT = 30
=======
TIMEOUT = 60
>>>>>>> theirs

Resolving means understanding both intents (maybe the answer is 60 with a new retry), editing the file, running the tests, then git add and continuing. Never leave markers in: a CI check that searches for <<<<<<< catches accidents.

In plain words: a conflict isn't an error. It's Git saying two people changed the same lines, and asking you to decide.

def merge(base, ours, theirs):
    out, conflicts = [], 0
    for b, o, t in zip(base, ours, theirs):
        if o == t:
            out.append(o)
        elif o == b:
            out.append(t)
        elif t == b:
            out.append(o)
        else:
            out.append(f"CONFLICT({o} / {t})")
            conflicts += 1
    return out, conflicts

base =   ["price = 10", "tax = 0.2", "name = 'tent'"]
ours =   ["price = 12", "tax = 0.2", "name = 'tent'"]
theirs = ["price = 10", "tax = 0.2", "name = 'big tent'"]
print(merge(base, ours, theirs))

theirs = ["price = 15", "tax = 0.2", "name = 'tent'"]
print(merge(base, ours, theirs))

Commands worth knowing

You'll use these more than you expect, especially when something has gone wrong. The one to remember: when a bad commit has reached main and teammates have pulled it, git revert adds a new commit that undoes it, while git reset rewrites history and breaks their copies.

Secrets: if a key is ever committed, removing it in a new commit isn't enough; it's still in history, like a page you crossed out in a diary that's still in the old copies. Revoke the key at once, then clean history if needed.

from difflib import SequenceMatcher

base = ["import os", "TIMEOUT = 30", "RETRIES = 3", "def main():"]
ours = ["import os", "TIMEOUT = 60", "RETRIES = 3", "def main():"]

for tag, i1, i2, j1, j2 in SequenceMatcher(None, base, ours, autojunk=False).get_opcodes():
    if tag != "equal":
        print(tag, f"base[{i1}:{i2}] -> {ours[j1:j2]}")

from difflib import SequenceMatcher

base = ["a", "b", "c"]
ours = ["a", "B", "c", "d"]
print([op[0] for op in SequenceMatcher(None, base, ours, autojunk=False).get_opcodes()])

Conflicts are questions, not obstacles

When Git marks a conflict, it's telling you two people changed the same lines and it can't decide. The tempting move is to pick one side and carry on. But each side was written for a reason, and picking blindly throws away someone's change. Read both, and work out what the code needs to do now, since the right answer is often a mix. If you don't understand the other change, ask whoever wrote it. Then run the tests, since code can merge cleanly and still be wrong.

Force-pushing shared branches

After a rebase, your branch has new commit ids, so pushing needs force. On your own branch, that's fine. On a branch others use, it rewrites history under them, and their next pull turns into a mess of duplicates. If you must force-push, prefer --force-with-lease, which refuses if someone else has pushed since you last looked.

A deleted secret isn't gone

If a key was committed and you remove it in the next commit, it's still in the history, and anyone with the repository can read it. Bots scan public repositories for keys within minutes. Treat any committed secret as leaked. Revoke it first, then think about cleaning the history. Rewriting history alone doesn't help if someone has already copied it.

Small pull requests

One page handed back the same day rarely clashes with anyone. Small changes merge with fewer conflicts.