Don't Overlook Workflow (as a Small Data Team)
Jan 07, 2026
A small data team, even a team of one, shouldn't skip the version control workflow. Having a Git project is not the same as following a Git workflow: a lot of small teams back their SQL up to GitHub and stop there, with no branches, commits, reviews or pull requests. The workflow is what formalizes how you develop, so the process is repeatable, documented and something you can hand to the next person. It brings structure, automation and a cleaner history, and it only sticks if you practice it. Four habits to start with: commit early and often, use the platform's built-in automations, add a pull request template, and set merge rules like a required approval or passing checks.
Key takeaways
- Overlooking workflow because the team is small is a critical error. It matters just as much for a one-person team as for a 100-person team.
- A Git project is a backup. A Git workflow is branches, commits, pull requests, reviews and merges. Many small teams have the first and think they have the second.
- The point of the workflow is to formalize development: a repeatable structure you can pass on to someone else or grow into.
- Version control is a habit. Use it consistently or it gets easier to put off and harder to pick back up.
- The three main benefits are structure in the development process, efficiency through automation, and a cleaner history of what changed and who approved it.
- Commit early and often. One giant commit at the end feels safe but makes rollbacks and reviews harder.
- A pull request template and merge rules, like one required approval or passing checks, keep you honest without adding overhead.
Why small teams skip it
When you're the only engineer at the company, or one of two, it's easy to feel like certain workflow steps are more work than they're worth. Nobody else sees the code, so why go through the ceremony?
I see this most often with version control. In my opinion, skipping it is a critical error, and that holds whether you're a one-person data team or a 100-person team.
A Git project vs a Git workflow
There's a difference between having a Git project and following a Git workflow. Many small teams have the first and believe they have the second.
What a Git project alone looks like
Your SQL queries and project files are technically backed up on a version control platform. It's a historical reference for the code, and that's a good thing.
But nobody is:
- Creating a branch when they start developing
- Making commits with commit messages as they go
- Opening a pull or merge request
- Reviewing and merging code through the platform
It's a backup. Saving the file somewhere safer than the laptop.
What the workflow adds
Setting up the repo is a great first step, but using it as a backup leaves most of the platform's functionality and options untouched.
More importantly, the workflow is what formalizes how your team develops. That's really what this is all about. A structure that's repeatable, that you can pass on to someone else, and that holds up as the team grows.
Making it a habit
Teams underuse version control for different reasons. Often it's a lack of education or experience with this kind of tooling, and that's understandable.
When I first got into data engineering, version control, automation and environments were all a little confusing. It didn't click until I was on a team that used them every day. Now I can't imagine working on a team, or even building something personally, without them.
It works like any other habit. You have to practice it and use it consistently. Otherwise it gets easier to put off, and over time harder to pick back up. That's why I tell teams to start now, whatever their size.
The main benefits
Three things you get from a real version control process that you don't get from a backup.
1. Structure in the development process
There's a system, so everyone knows exactly what developing code involves: create a branch, commit changes, push, get a review, merge. No guessing, and nothing that only lives in one person's head.
2. Efficiency through automation
Teams that aren't using version control to its potential tend to do a lot by hand: manual testing, manual deployments, manual documentation.
The platform can automate all of that once you understand how to incorporate it into the workflow. Less manual work, fewer things forgotten.
3. A cleaner history
The code stays cleaner because of reviews. The documentation of what changed gets cleaner too.
Instead of a pile of files, you have a tracked record of individual changes through history. With pull requests and a template, you can look back at each batch of changes, who approved it, and the conversation around it.
That matters most when you're no longer at the company or the team expands. The context lives in one structured place instead of being scattered across chat channels and random parts of the code.
Four habits to adopt
Whether you're improving an existing process or starting from scratch, these are the tips I'd pass on.
Commit early and often
Commit to your development branch in small chunks as you go. I learned this early in my experience with these platforms and it has held up.
Each commit has a message, so you can see the small things that happened and track them individually. Smaller commits also make it easier to roll back one piece of code if you ever need to, without undoing everything.
The common mistake is the opposite. A team follows the process on paper, makes a pile of changes, and then does one really large commit at the very end before moving it along.
It can feel safer, like you're waiting until you're sure. In reality you're making the future harder on yourself. Nuances slip through in a big change, and it's much easier to read several small ones than to work out what happened in one large one.
Don't be scared to commit. Make it part of the process.
Use the automations
The platforms come with solid automation you can set up to deploy your code, test it and create documentation. A lot of it is right out of the box. You just have to know where to look.
AI tooling makes much of this easier to set up than it used to be, so there's less reason than ever to leave it idle.
Add a pull request template
A template gives every pull or merge request the same look and feel. Reviews get easier, and it keeps you on track without adding overhead, because it pulls up automatically each time you create one.
It also pushes back on the tendency to leave the description blank. At the very least you're consciously deleting a template to write nothing. Usually people add at least a little, and the template makes that less painful.
Set rules on the merge
Every platform lets you add rules around the merge request process. Two I'd recommend:
- At least one approval from someone else before code can be merged
- All automated checks must pass before the merge button activates
Both keep the structure in place regardless of team size. If you're a team of one, the passing-checks rule still applies and still catches broken code before it merges.
The size of the team doesn't change the answer
Workflow is an important component for any data team, whether that's one person or a hundred. If you're the solo engineer, you're also the person who'll have to explain every change later, and the person who'll hand it over one day.
The habits above are how you make that handover a non-event.
Key terms
Git workflow
The process of developing through version control: create a branch, commit changes, push, open a pull request, get a review, merge. As opposed to using the repo only as a backup.
Development branch
A copy of the code where you make changes in isolation from the main branch until they're reviewed and merged.
Commit early and often
The habit of saving small, frequent commits with messages as you develop, instead of one large commit at the end.
Pull request template
A file in the repo that pre-fills the description every time a pull or merge request is opened, so every request is documented the same way.
Merge rules
Platform settings that block a merge until conditions are met, such as one approval from another person or every automated check passing.
Common questions
Does a one-person data team need a Git workflow?
Yes. The branch, commit and pull request process gives you a documented history of every change, which you'll need when you forget why something was done or when you hand the work to someone else. It's also what makes automated testing and deployment possible.
What's the difference between using Git as a backup and a Git workflow?
A backup means the files are stored on GitHub or GitLab but you edit and save them directly. A workflow means changes go through branches, commits, pull requests and reviews before they reach the main branch. The second is what formalizes your development process.
How often should I commit in a data project?
Early and often. Commit each small, logical change with a short message as you go. Small commits are easier to review and easier to roll back than one large commit at the end of a long piece of work.
What rules should I set on merging to the main branch?
Two good defaults: require at least one approval from someone else, and require all automated checks to pass before the merge button is enabled. Every major version control platform supports both.
How do I get a small data team to actually use version control?
Treat it as a habit. Start with the full process on every change, even small ones, so it becomes routine. A pull request template and merge rules make the right behaviour the default, and the automation that comes with it is usually the thing that convinces people.
Related reading
- 5 Ways To Improve Your Data Workflow
- 3 Simple Ways to Improve Your Data Workflow
- The Gift & Curse of Small Data Teams
- Why Data Teams Need Version Control
Final takeaway
The small teams I work with that struggle most are rarely short on skill. They're short on process, and version control used as a backup is the most common version of that. Follow the workflow from the start, even alone, and everything else about running the team gets easier.
Additional Free Resources
Starter Guides & Checklists
Explore additional free resources built on the same patterns I use with real clients so you can build your own with structure and confidence. Topics include data architecture, modeling and more specifically for small data teams.
