What we build with it
Git is not a preference, it is the substrate — but how a team uses it is a real choice, and it shows up in how easy a codebase is to work on a year later.
Our default is short-lived branches off a trunk that always builds, one reviewed pull request per change, and CI running tests, lint and a build on every push. Commits are written to be read: a message that explains why, not a restatement of the diff.
Where it fits
Every engagement, including work inside a client's own repository. When we join an existing team through team augmentation, we adopt their branching model and review conventions rather than importing ours — consistency inside one repo is worth more than any particular workflow being objectively better.
When we recommend it
For the workflow above: trunk-based development with small, frequently merged branches. Long-lived feature branches are where merge pain and stale code come from, and the cost lands weeks after the decision that caused it.
Where we push back is on process for its own sake — mandatory squashing, rigid commit-message formats, or a branching model with five permanent branches on a team of three. The point is a history you can bisect and a review that catches things, not ceremony.