Every Team Makes These Four Decisions When Using Git

By Matias Denda – May 31 2026

Git has become the default version‑control system for most software shops, yet teams often stumble over the same set of questions when they first adopt it. The issues aren’t about syntax or commands; they’re about the policy layer that sits on top of the tool. In my experience, every team, regardless of size or domain, ends up making four core decisions:

1. Branching model – How do we organise work in the repository?
2. Commit granularity – How small or large should each commit be?
3. Release cadence – How often do we ship code to production?
4. History hygiene – When do we rewrite history and when do we preserve it?

Below I walk through each decision, why it matters, and a few concrete patterns that have proven useful across different contexts.

---

1. Branching Model

The problem

A branching model defines the workflow for feature development, bug fixes, and releases. The wrong model can cause merge chaos, long‑running feature branches, or a flood of hot‑fixes that break the main line.

Common options

Model	Typical use‑case	Trade‑offs
GitHub Flow (single main + short‑lived PRs)	Startups, continuous‑delivery teams	Very fast feedback, but requires automated testing to be solid.
Git Flow (develop, release, hotfix branches)	Enterprises with scheduled releases	Clear separation of concerns, but adds overhead and can delay integration.
Trunk‑Based Development (feature flags, tiny branches)	Large micro‑service ecosystems	Reduces merge friction, but relies heavily on feature‑flag discipline.

Choosing a model

1. Product cadence – If you ship daily, GitHub Flow or trunk‑based is a natural fit.
2. Regulatory constraints – Industries that need audit trails may prefer Git Flow’s explicit release branches.
3. Team maturity – New teams benefit from the simplicity of GitHub Flow; seasoned teams can handle the extra branches of Git Flow.

Practical tip: Start with the simplest model that satisfies your release cadence, then iterate. Adding a release branch later is easier than rolling back to a more complex workflow.

---

2. Commit Granularity

The problem

Large, monolithic commits make code review painful and obscure the intent of changes. Tiny, overly fragmented commits can drown reviewers in noise.

Guiding principles

• Atomicity: Each commit should represent a single logical change—whether that’s a bug fix, a refactor, or a new feature.
• Self‑documenting: The commit message should explain why the change was made, not just what was changed.
• Testability: A commit should compile and pass the test suite on its own.

Real‑world patterns

• “Feature‑first, refactor‑later” – Begin with a commit that adds the feature, then follow up with a separate commit that cleans up the code.
• “Split by concern” – If a change touches UI, backend, and documentation, create three commits rather than one catch‑all.

Tooling help: Use git add -p to stage hunks interactively, and configure a pre‑commit hook that runs npm test or go test to enforce buildability.

---

3. Release Cadence

The problem

How often you push to production influences everything from branching to testing. A mismatch between release cadence and branching model creates bottlenecks.

Cadence categories

Cadence	Typical branch strategy	Automation needs
Multiple releases per day	Trunk‑based, feature flags	Full CI/CD pipeline, canary releases
Weekly/Bi‑weekly	GitHub Flow with a main branch	Automated integration tests, staged rollouts
Monthly or longer	Git Flow with release branches	Manual QA gates, release notes generation

Aligning cadence with business goals

• Customer expectations: SaaS products often promise rapid iteration; a slower cadence can erode trust.
• Risk tolerance: Highly regulated domains may need longer cycles for compliance checks.
• Team bandwidth: Over‑ambitious release schedules can lead to burnout and technical debt.

Actionable step: Map your current release frequency to a visual timeline, then identify friction points (e.g., long merge windows) and adjust the branching model accordingly.

---

4. History Hygiene

The problem

A messy commit history hampers debugging, while an overly pristine history can hide useful context. Deciding when to rewrite history (squash, rebase) versus when to preserve it (merge commits) is a cultural choice.

When to rewrite

• Feature branches before merge: Squash‑and‑merge to keep main linear and readable.
• Local work: Rebase to keep your own branch tidy before opening a pull request.

When to preserve

• Public branches: Avoid rebasing main or any branch that others have already pulled.
• Audit trails: Keep merge commits for releases that need a clear point‑in‑time snapshot.

Recommended workflow

1. Develop locally – Use git rebase -i to clean up commits.
2. Open PR – Push the cleaned branch to the remote.
3. Merge – Choose Squash and merge for small features, Merge commit for releases.

This hybrid approach gives a readable main line while still retaining the ability to trace back to the original work when needed.

---

Bringing It All Together

Imagine a mid‑size fintech startup that ships new features every two weeks but must retain an audit‑ready history for regulators. A practical configuration could be:

1. Branching model: Git Flow – develop for ongoing work, release/* for the two‑week sprint, hotfix/* for emergency patches.
2. Commit granularity: Enforce atomic commits via a pre‑commit hook that checks for a conventional commit format.
3. Release cadence: Two‑week release cycle, automated CI that runs integration tests on the release/* branch before merging to main.
4. History hygiene: Squash feature branches when merging into develop, keep merge commits for release/* → main to preserve a clear production snapshot.

By aligning each of the four decisions with the product’s constraints, the team avoids the typical git‑related friction points—merge conflicts that linger for days, unclear release histories, and a backlog of half‑finished branches.

---

Final Thoughts

The four decisions outlined above are not independent checklist items; they form a feedback loop. Changing the release cadence often forces a revision of the branching model, which in turn influences how you think about commit granularity and history hygiene. The key is to treat Git as a living part of your development process, not a static set of commands.

When a team revisits these choices regularly—say, during a quarterly retrospection—they can keep their workflow lean, their history useful, and their releases predictable. That’s the real value of mastering Git: not just a tool that stores code, but a framework that shapes how a team delivers software.

---

If you’d like to see the full slide deck I use for workshops on Git strategy, check out the Git in Depth repository. The repo includes example branch structures, commit‑message templates, and CI configuration snippets you can drop into your own pipelines.