Git version control
Nobody buys Git. It still decides three things people do buy: whether you can take a codebase on safely, whether you can hand one over cleanly, and what a repository says about a system before anyone quotes the work.
01Overview
A distributed history, not a server you log into
Git is a distributed version control system. Every clone holds the project's whole history, so the record can be verified and not quietly rewritten. GitHub, GitLab, Bitbucket and Azure Repos are products built on top of it. When a team says GitHub, they usually mean their review process.
02Capabilities
Three habits that decide how fast you can change code safely
Three habits, applied on our own projects and inside client repositories alike. None of them is exotic, and their absence is reliably expensive. Taking on somebody else's system is a large part of the work: one published example is stabilizing a home health monitoring platform, a system we were asked to steady rather than start.
- Branches
Short-lived branches off main
One branch per change, merged in days rather than weeks, with anything unfinished hidden behind a flag instead of parked on a branch. Long-lived branches are not isolation, they are deferred merge pain accruing interest.
- Review
Review as a gate, not a formality
Every change is read by someone who can say no, and the diff is kept small enough that saying no is realistic. Branch policies enforce it in the tool, and the automated tests from our QA practice run before merge rather than after.
- History
History that helps you debug
Commit messages that explain why, linked to the work item, so an old regression can be traced and a release reconstructed. In fintech and other regulated work, who changed what and who approved it stops being hygiene and becomes an audit artifact.
03Fit
Taking a codebase on, and handing one over
Almost every repository we take over shows some of the following. None is catastrophic on its own, and together they are usually why shipping feels slow for reasons nobody can name. Five of the six rows below point away from anything we would call Git work, and two of them name no unicrew page at all.
| What you are doing | What that actually needs |
|---|---|
| Taking on a system somebody else has been shipping for years | Read it firstThe history, the tests and the build tell you more about the cost than a specification will. If you want that read on its own rather than as project setup, it is a quality audit. |
| Handing a codebase to another team, or back to your own | Different pageWhat has to exist is the release path, the runbook and a named owner, not a tidy repository. Our DevOps consulting page covers that handover. |
| Nobody can build the default branch from a clean clone | Fix that firstNothing else here matters until a fresh clone builds on its own. That is pipeline work, and it comes before any feature anyone would quote. |
| It builds, but only on one machine somebody configured years ago | Different pageThat is a packaging problem rather than a version-control one. Our Docker page covers making a build reproducible somewhere other than that machine. |
| Credentials are somewhere in the history | Rotate before anythingRewriting history does not un-leak a key that has already been cloned. Rotate first, then clean, then check forks, mirrors and pipeline caches. |
| You want branch policies, work-item links and gated builds in one place | Different pageThat is a hosting and automation choice layered on top of Git. Our Azure DevOps page covers what it buys you and what it costs to run. |
Scope
We work inside your repository, on branches, through your review process. You can see and stop everything. What we own is the consequence: whether the default branch can be trusted, and whether your team can still release after we stop. Every change is read by someone who can say no. unicrew has worked in client repositories since 2012, with 100+ senior in-house engineers across six countries. We work under an ISO 27001:2022 certified information-security management system.
04Stack
The products bolted on around it
Three neighbours of a repository decision, each with a page of its own if that is the call you are really making.
05Questions
Asked before we get access
Answered the way we would answer them on a call, including where the answer is to change nothing.
Yours, on branches, through your review process, with your engineers approving changes. That is deliberate. It keeps you able to see and stop everything, and it removes the handover event at the end of a project. Where we start something from nothing, we set the repository up inside your organization on day one rather than moving it later, so ownership is never a migration.
Whether the default branch builds from a clean clone, whether the tests run and what they cover, how releases are identified, and whether live secrets sit in the tree. Then the shape of the history: how big a typical change is, and how long branches live. Those five answers move an estimate more than a long conversation about architecture will.
It follows your release cadence rather than your taste. If you release on demand, main plus short branches is simpler and safer, with tags marking what shipped. Git flow earns its complexity only where you genuinely maintain several versions at once, such as on-premise software with supported older releases. Running git flow while deploying every day is the mismatch we see most often, and it is expensive.
Yes, in this order: rotate the exposed credentials, rewrite the history with a tool built for it, then coordinate a fresh clone for everyone, because rewritten history breaks existing checkouts. The rotation is not optional and it comes first. Treat anything ever pushed to a shared remote as public, including in a private repository, since clones, forks, mirrors and pipeline caches all keep copies.
Fewer than you think, and release coupling decides it rather than tidiness. Components that always ship together belong in one repository, where a single change and a single review cover the whole thing. Components with independent release cycles and different owners are cleaner apart. Splitting a codebase to look organized, then coordinating synchronized releases across four repositories, is the version of this that hurts. Our maintenance and support work inherits both shapes.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Want the read before you sign anything?
Give us read access to the repository. You get an engineer's read on what is in there, what will slow you down, and what we would fix first. The delivery side of that is DevOps consulting, and the ongoing side is maintenance and support.