Branching Strategies and Code Review

A branch is an isolated line of development in a version-controlled codebase — a copy of the code that one person (or one feature) can change without affecting anyone else's copy until the changes are deliberately merged back together. Without branches, everyone would have to edit the same shared code at the same time, and one person's half-finished, broken change would block or break everyone else's work. The basic pattern almost every team follows is: keep one branch (often called main) always in a working, deployable state, and do new work on a short-lived branch that only gets merged back once it's finished and reviewed.

Teams differ mainly in how strict they are about that pattern and how long branches are allowed to live. A common lightweight approach has each new feature or fix live on its own branch, opened from main, merged back via a reviewed pull request, and deleted once merged — branches typically live hours to a few days. Longer-lived branches (a whole release branch kept alive for weeks) reduce how often people have to coordinate, but increase the risk of a large, painful merge later, since the longer two branches diverge, the more likely they are to have made conflicting changes to the same code.

Code review — having someone other than the author look over a change before it merges into main — catches a different class of problem than automated tests do. Tests check whether the code does what the author intended; a reviewer checks whether what the author intended was actually right, whether an edge case was missed, whether the change interacts badly with something elsewhere in the codebase the author didn't think to check. This matters more, not less, in a quant codebase where a subtle logic error — an off-by-one in a lookback window, a sign flip in a position calculation — doesn't crash anything but quietly produces wrong trades or wrong backtests, exactly the kind of mistake a second reader is more likely to catch than a test the original author wrote with the same blind spot.

Worked example: catching a sign error before it merges

A developer submits a pull request changing how a hedge ratio is applied to a position, and the code passes every existing automated test, because those tests were written under the same mental model that has the bug — everything self-consistently agrees with itself. A reviewer, reading the diff independently, notices the hedge ratio is being subtracted where the rest of the codebase's convention is to add it, flags the sign mismatch, and the author confirms it was a genuine bug that would have inverted the hedge in production. The tests didn't catch it because the tests shared the author's incorrect assumption; a second person reading the logic with fresh eyes did.