Guide
Git and version control in a team
Git answers "who changed what, and when". What it does not solve on its own is how a team coordinates around it: that is a convention you have to decide and write down.
Last updated:
Almost no team has a problem with Git as a tool. The problem is the lack of agreement: everyone branches their own way, reviews depend on who is on call, and nobody is quite sure what is in production. This guide covers the decisions worth settling and why.
Choosing a branching model
There are two sensible families and one that is usually overkill. Trunk-based: everyone integrates into main several times a day, behind feature flags if needed, and releases from there. GitFlow: long-lived branches (develop, release/*, hotfix/*) with a promotion ritual between them.
- Small team (2–8) that deploys often: trunk-based with short-lived branches (hours or a couple of days).
- Product with numbered versions, several supported at once, or per-version certification: GitFlow or a variant.
- A branch that lives for weeks without integrating is not a strategy, it is debt: the merge will be costly and risky.
Pull requests that are worth something
A pull request is a unit of review, not a two-week data dump. The smaller it is, the more honest the review: past 400 lines, the reviewer approves out of fatigue.
- One change per PR, with a description of the problem it solves and how to test it.
- The branch starts from an up-to-date
mainand merges back within days, not weeks. - CI (tests, lint, build) passes before human review is requested, not after.
- At least one approval from someone other than the author, and that person is genuinely able to say no.
Code review: what to look at
Review is not a style check — a linter does that automatically. It is a conversation about whether the change is correct, whether it is the simplest solution, and whether someone else will be able to maintain it. Commenting on a variable name while a concurrency bug slips through wastes everyone's time.
Versioning and releases
Tag every release (git tag) with semantic versioning and a changelog generated from commit messages. Then, when something breaks in production, the question "what went into this version?" is answered in ten seconds rather than by reconstructing history by hand.
FAQ
What people ask us
Trunk-based or GitFlow?
Trunk-based if you deploy often and do not maintain several versions at once; GitFlow if you have numbered versions supported in parallel. When in doubt, trunk-based with short-lived branches causes fewer problems.
Do all pull requests need review?
Yes, even if the review is quick. The value is not only catching bugs: it is that more than one person knows each part of the code and nobody is a single point of failure.
How large can a pull request be?
As a rule, under 400 lines of real change. Beyond that, review quality drops sharply. If a change is unavoidably large, split it into several chained PRs.
Do commit messages need a format?
It helps a lot. With Conventional Commits you can generate the changelog and decide the version number automatically, and the history becomes readable.
Related services
Next step
Half an hour well spent
Walk us through the problem on a short call. You leave with a first read on how we'd approach it and what it would involve — no commitment, no sales deck.