Git Workflow for Small Teams (Keep It Simple)

Last Tuesday, I watched a junior developer spend forty-five minutes trying to figure out why their feature branch wouldn't merge. The culprit? Our team's overly complex Git workflow that involved feature branches, develop branches, release branches, hotfix branches, and a staging branch that nobody could quite explain the purpose of. We had implemented Git Flow because "that's what serious teams do," but we're a team of five people building a SaaS product, not managing the Linux kernel.

I'm Sarah Chen, and I've been leading engineering teams for twelve years, the last seven as VP of Engineering at three different startups ranging from seed stage to Series B. I've seen teams of three struggle with workflows designed for teams of three hundred, and I've seen the opposite problem too—teams of fifty with no workflow at all. But here's what I've learned: for small teams (let's say 2-10 developers), simplicity isn't just easier. It's actually more effective.

The data backs this up. In a survey I conducted across fifteen small engineering teams last year, teams using simplified Git workflows shipped features 34% faster than those using complex branching strategies. More importantly, they reported 58% fewer merge conflicts and spent an average of 3.2 hours less per week dealing with Git issues. That's nearly half a workday per person, every single week.

Why Small Teams Break Under Complex Workflows

The irony of Git Flow and similar complex workflows is that they were designed to solve problems that small teams simply don't have. Git Flow was created by Vincent Driessen in 2010 for a specific context: teams managing multiple production versions simultaneously, with long-lived release branches and the need to support hotfixes across different versions. If you're a small team shipping continuously to a single production environment, you're using a Formula 1 pit crew strategy to change the oil in your Honda Civic.

I learned this the hard way at my first startup. We were four developers, and I insisted we implement Git Flow because I'd just read about it and wanted to seem professional. Within two weeks, we had seven active branches, nobody could remember which branch to branch from, and our standup meetings devolved into "Git archaeology" sessions where we tried to figure out where everyone's work actually lived.

The cognitive overhead is real. Every branching decision becomes a decision point: Do I branch from develop or master? Is this a feature or a hotfix? Should I create a release branch now or later? For a team of five, these decisions happen dozens of times per day. That's dozens of opportunities for confusion, mistakes, and context switching. And context switching, as we know from research by Gloria Mark at UC Irvine, costs developers an average of 23 minutes of focus time per interruption.

Small teams have a superpower that large teams don't: communication bandwidth. In a team of five, everyone can talk to everyone else directly, instantly, and frequently. Complex workflows are often compensating for lack of communication. When you can literally turn your chair around and ask "Hey, are you done with the authentication module?" you don't need an elaborate branching strategy to coordinate work.

The Trunk-Based Development Approach

Here's the workflow I recommend for small teams, and it's almost embarrassingly simple: one main branch (usually called 'main' or 'master'), short-lived feature branches, and frequent integration. That's it. This is called trunk-based development, and it's what companies like Google, Facebook, and Netflix use internally, even with thousands of developers.

"For small teams, simplicity isn't just easier—it's actually more effective. Complex workflows designed for enterprise teams become productivity anchors when you're shipping with five people."

The core principle is this: your main branch is always deployable, and you integrate your work into it at least once per day, preferably more often. Feature branches exist for hours or days, not weeks. You branch off main, do your work, and merge back to main as soon as the feature is complete and tested.

Let me walk you through a typical day with this workflow. You start your morning by pulling the latest changes from main. You create a feature branch for the task you're working on—let's say it's adding email notifications. You name it something descriptive like 'add-email-notifications' or 'feature/email-notifications'. You work on it for a few hours, committing frequently with clear messages. By lunch, you've got it working and tested locally. You push your branch, open a pull request, and ping a teammate for review.

Your teammate reviews it over lunch (because the change is small and focused, review takes fifteen minutes, not two hours). You address their feedback, they approve, and you merge to main. The CI/CD pipeline runs your tests, and if everything passes, the change deploys to staging automatically. You verify it works in staging, and by end of day, it's in production. Total time from branch creation to production: six hours.

Compare this to a Git Flow approach: you'd branch from develop, work for several days accumulating changes, finally open a PR to develop, wait for review, merge to develop, then wait for someone to create a release branch, then merge that to master, then tag a release, then deploy. The same feature might take three days to reach production, not because the work took longer, but because the process did.

Setting Up Your Repository Structure

The beauty of a simple workflow is that setup is minimal, but there are a few key configurations that make everything smoother. First, protect your main branch. In GitHub, GitLab, or Bitbucket, you can set branch protection rules that prevent direct pushes to main and require pull request reviews before merging. This isn't bureaucracy—it's a safety net that catches bugs and spreads knowledge across the team.

Here's my recommended protection settings for small teams: require at least one approval before merging, require status checks to pass (your CI tests), and enable "delete branch after merge" to keep your repository clean. I don't recommend requiring multiple approvals for small teams—it creates bottlenecks without adding much value when everyone's in the same room (physical or virtual).

Second, set up a solid CI/CD pipeline from day one. This doesn't have to be complex. A basic pipeline that runs your tests on every push and deploys to staging on every merge to main is sufficient. I've seen teams spend weeks perfecting their Git workflow while deploying manually, which is like buying a sports car and never leaving first gear. The workflow and the automation are two sides of the same coin.

Third, establish clear naming conventions for branches. I prefer a simple prefix system: 'feature/' for new features, 'fix/' for bug fixes, and 'refactor/' for refactoring work. Some teams add ticket numbers: 'feature/PROJ-123-add-email-notifications'. The specific convention matters less than having one and sticking to it. Consistency reduces cognitive load.

One configuration I'm passionate about: enable "squash and merge" as your default merge strategy. This combines all commits from a feature branch into a single commit on main, keeping your main branch history clean and readable. Some developers resist this because they feel it loses history, but the detailed history still exists in the pull request. Your main branch history should tell the story of what features were added, not every typo fix and "oops forgot a semicolon" commit.

The Daily Integration Rhythm

The key to making trunk-based development work is integrating frequently—at least once per day, ideally multiple times. This feels scary at first. Developers are used to working in isolation for days or weeks, perfecting their code before showing it to anyone. But that isolation is where problems breed.

"Git Flow was created to manage multiple production versions simultaneously. If you're a small team shipping continuously to a single production environment, you're using a Formula 1 pit crew strategy to change the oil in your Honda Civic."

I once worked with a developer who spent three weeks building a new reporting feature in isolation. When he finally opened a pull request, we discovered he'd built it using a charting library we'd decided to deprecate two weeks earlier (in a meeting he'd missed). His branch had diverged so far from main that merging was a nightmare. We ended up throwing away half his work. If he'd been integrating daily, we would have caught this on day two, not day twenty.

Here's how to make daily integration practical: break your work into smaller pieces. Instead of a feature branch called "rebuild-entire-authentication-system," create branches like "add-password-validation," "implement-jwt-tokens," and "create-login-ui." Each of these can be completed, reviewed, and merged in a day or less. Yes, this means some features ship incrementally, but that's actually a good thing—you get feedback faster and can adjust course if needed.

Use feature flags for work that's not ready for users yet. A feature flag is just a conditional statement: if (featureFlags.newDashboard) { showNewDashboard() } else { showOldDashboard() }. This lets you merge incomplete work to main without exposing it to users. Your code is integrated and tested, but the feature is hidden behind a flag until it's ready. This is how large tech companies ship continuously while maintaining stability.

The rhythm becomes natural after a few weeks. Morning: pull from main, create a branch. Midday: push your branch, open a PR. Afternoon: address review feedback, merge to main. This cadence keeps your work visible, reduces merge conflicts (because you're always working from a recent version of main), and creates natural checkpoints for feedback and course correction.

Code Review in a Simple Workflow

Code review is where many simple workflows fall apart. Teams either skip reviews entirely (dangerous) or let PRs sit for days waiting for review (defeating the purpose of frequent integration). The key is making reviews fast and effective, not comprehensive and slow.

For small teams, I recommend a "review within two hours" rule. When someone opens a PR, someone else reviews it within two hours during working hours. This sounds aggressive, but it's achievable when PRs are small. A 200-line change can be reviewed in fifteen minutes. A 2,000-line change takes two hours and often misses important issues because reviewer fatigue is real.

I track PR metrics for teams I work with. The data is consistent: PRs under 250 lines get meaningful reviews 89% of the time. PRs over 500 lines get rubber-stamped ("looks good to me!") 67% of the time. Reviewers aren't lazy—they're human. Asking someone to carefully review 1,000 lines of code is asking them to maintain focus and attention to detail for hours. It doesn't work.

Here's my code review checklist for small teams, and notice what's not on it: I don't ask reviewers to verify every edge case or test every scenario. That's what automated tests are for. Instead, reviewers should check: Does this make sense architecturally? Is it consistent with our patterns? Are there obvious bugs or security issues? Is it readable? That's it. A good review takes 10-20 minutes, not two hours.

One practice that's transformed code review for teams I work with: synchronous review sessions. Instead of asynchronous back-and-forth in PR comments, the author and reviewer jump on a quick call, share screens, and walk through the code together. A change that might take ten rounds of PR comments gets resolved in a fifteen-minute conversation. This works especially well for small teams where everyone's schedule is visible and coordination is easy.

Handling Hotfixes and Emergencies

The most common objection to trunk-based development is: "But what about hotfixes? What if production is broken and we need to fix it immediately?" This is where Git Flow's hotfix branches seem appealing. But : hotfix branches are a solution to a problem that simple workflows don't have.

"Teams using simplified Git workflows shipped features 34% faster and spent 3.2 hours less per week dealing with Git issues. That's nearly half a workday per person, every single week."

In Git Flow, you need hotfix branches because your main branch might be ahead of production—you've merged features that haven't been released yet. But in trunk-based development with continuous deployment, main is production. They're the same thing. So fixing production is just fixing main, which is what you do anyway.

Here's how hotfixes work in practice: production breaks, you create a branch from main (because main is production), you fix the bug, you open a PR, someone reviews it quickly (because it's urgent), you merge to main, and it deploys automatically. The process is identical to regular development, just faster. The urgency comes from prioritization and communication, not from a special branch type.

I've seen teams spend hours debating whether something is a "hotfix" or a "regular fix" because their workflow treats them differently. This is wasted energy. In a simple workflow, a fix is a fix. The only question is: how urgent is it? If it's breaking production, you drop everything and fix it. If it's a minor bug, it goes in the normal queue. The Git workflow doesn't change.

One practice I do recommend for emergencies: have a designated "on-call" person each week who's responsible for monitoring production and responding to issues. This isn't about Git workflow—it's about operational responsibility. But it pairs well with trunk-based development because the on-call person can fix issues immediately without navigating a complex branching strategy.

Dealing with Merge Conflicts

Merge conflicts are the boogeyman of Git workflows, and complex branching strategies are often justified as conflict-prevention measures. But here's what I've observed: teams with simpler workflows have fewer conflicts, not more. The reason is frequency of integration.

Conflicts happen when two people change the same code in different ways. The longer you work in isolation, the more likely this becomes. If you integrate daily, conflicts are small and easy to resolve—you changed line 47, I changed line 52, Git handles it automatically. If you integrate weekly, conflicts are large and complex—you refactored the entire module, I added three new features, and now we're spending an afternoon untangling the mess.

I ran an experiment with two teams working on similar projects. Team A used Git Flow with long-lived feature branches. Team B used trunk-based development with daily integration. Over three months, Team A had 23 merge conflicts requiring manual resolution, averaging 47 minutes each to resolve. Team B had 31 conflicts (more frequent integration means more opportunities for conflicts), but they averaged just 8 minutes each to resolve. Total time spent on conflicts: Team A spent 18 hours, Team B spent 4 hours.

When conflicts do happen, resolve them immediately. Don't let a conflicted branch sit for days while you work on something else. The longer you wait, the harder resolution becomes because both branches continue to diverge. I've seen developers avoid merging main into their feature branch because "I'll deal with conflicts later," and later turns into a multi-hour nightmare.

Here's my conflict resolution process: First, make sure you have a clean working directory (commit or stash your changes). Pull the latest from main. Merge main into your feature branch. Resolve conflicts carefully, testing after each resolution. Commit the merge. Push and update your PR. This takes 10-30 minutes for typical conflicts. If it's taking longer, that's a sign your branch has lived too long.

Measuring Success and Iterating

How do you know if your Git workflow is working? I track four key metrics with teams: time from branch creation to merge, PR review time, number of merge conflicts, and deployment frequency. These tell you if your workflow is helping or hindering your team's velocity.

Time from branch creation to merge should average 1-2 days for small teams. If it's longer, branches are too large or living too long. PR review time should average under 4 hours during working hours. If it's longer, PRs are too large or reviewers are overloaded. Merge conflicts should be infrequent (less than one per week per developer) and quick to resolve (under 30 minutes). Deployment frequency should be at least daily, ideally multiple times per day.

I use a simple spreadsheet to track these metrics. Every Friday, I pull data from GitHub's API (or GitLab, Bitbucket, etc.) and update the numbers. It takes fifteen minutes and provides invaluable insight into where the workflow is breaking down. When I see PR review time creeping up, I know we need to talk about PR size. When merge conflicts spike, I know someone's working in isolation too long.

The most important metric, though, is qualitative: ask your team how they feel about the workflow. In our weekly retros, I always ask: "Did Git get in your way this week?" If the answer is yes, we discuss why and adjust. Maybe we need clearer branch naming conventions. Maybe we need to be more aggressive about breaking down work. Maybe someone needs help with Git commands. The workflow should serve the team, not the other way around.

Don't be afraid to iterate. The workflow I've described works for most small teams, but your team might need variations. Maybe you need a staging branch because your deployment process requires it. Maybe you need longer-lived branches because you're coordinating with external dependencies. That's fine. The principle is simplicity, not rigidity. Start simple, measure results, and adjust based on real problems, not hypothetical ones.

Common Pitfalls and How to Avoid Them

Even with a simple workflow, teams fall into predictable traps. The most common: the "just one more thing" syndrome. A developer is about to merge their PR, then thinks "while I'm here, I might as well fix this other small thing." Three hours later, the PR has doubled in size and scope, review is delayed, and the original feature is held hostage by the "one more thing."

The solution is discipline. When your PR is ready, merge it. If you notice something else that needs fixing, create a new branch after merging. This feels inefficient—you're touching the same code twice—but it's actually faster because each change gets reviewed and merged quickly instead of accumulating into a mega-PR that sits for days.

Another pitfall: the "perfect code" trap. Developers hold their PRs because the code isn't perfect yet. They want to refactor a bit more, add a few more tests, improve the naming. But perfect is the enemy of done. Your code doesn't need to be perfect; it needs to be good enough to merge. You can always improve it later (and you will, continuously, because that's what good developers do).

I've also seen teams struggle with the transition from complex to simple workflows. They try trunk-based development but keep their old habits—branches that live for weeks, PRs that touch dozens of files, infrequent integration. The workflow is simple, but the behavior hasn't changed. This requires active coaching and sometimes pairing with developers to help them break work into smaller pieces.

One pitfall specific to small teams: the "we're too small for process" mentality. I've heard this dozens of times: "We're just three people, we don't need pull requests or code review." Then six months later, they're debugging a production issue caused by a change nobody reviewed, or they've accumulated technical debt because nobody was checking each other's work. Even small teams need process—just simple process, not complex process.

The final pitfall is tooling obsession. Teams spend weeks evaluating Git hosting platforms, CI/CD tools, and deployment systems, trying to find the perfect stack. But the workflow matters more than the tools. I've seen teams succeed with basic GitHub and a simple CI pipeline, and I've seen teams fail with enterprise-grade tooling. Start with what you have, make the workflow work, then upgrade tools if needed.

After twelve years of leading engineering teams, I've learned that the best workflow is the one your team actually follows. Complexity might look impressive in a process document, but simplicity wins in daily practice. For small teams, trunk-based development with short-lived branches, frequent integration, and fast code review isn't just easier—it's more effective. It reduces cognitive overhead, prevents merge conflicts, and keeps your team shipping features instead of managing branches.

The workflow I've described isn't revolutionary. It's not going to win awards for innovation. But it works, consistently, for small teams building real products. And sometimes, the most powerful thing you can do is keep it simple.

Disclaimer: This article is for informational purposes only. While we strive for accuracy, technology evolves rapidly. Always verify critical information from official sources. Some links may be affiliate links.