Why Your Slow-Cooked Sauce Is Basically Version Control
What coding in Git taught me about cooking (or was it the other way around?)
Git commit: add salt to taste
If you cook at home, there’s probably a massive pot on your stove that’s been going for three hours. You’ve tasted it four times. You added a pinch of something, waited, tasted again. “It’s still not done yet? Ugh.” But it’s closer than it was. And somehow, you already know you’ll make it differently next time.
That pot is also, whether you realize it or not, a version control system.
Stay with me here.
The Commit History You Never Knew You Had
In software development, version control is how engineers track changes to a codebase over time. Every edit, every fix, every experimental tweak gets logged: who changed what, when, and why. The most popular tool for this is Git, and its core unit is something called a commit: a snapshot of the project at a specific moment in time.
Your slow-cooked sauce works the same way. Every time you lift the lid and adjust? Add more salt? A splash of wine? Turn the heat down? Add the herbs later this time? That’s called a commit. A small, deliberate change to an evolving “thing.”
In a real codebase, it looks like this:
git add .
git commit -m “added anchovy paste, reduced heat to low, let rest 20 min”
That message? That’s your personal margin note. The sauce you’re serving tonight isn’t the one you started this morning. It’s the accumulated result of every decision, every taste, every correction. So then, you can see the whole story:
git log --oneline
a3f9c21 added anchovy paste, reduced heat to low, let rest 20 min
b81e04d splash of red wine, stirred in slowly
c29d17a salt adjustment — too flat, added more
e14a882 initial commit — base sauce, onions, tomatoes, olive oil
Some cooks keep a recipe notebook. Recipe notebooks consist of recipes that do not necessarily look like the original. It’s just the cook’s own version of it, with notes in the margins. Less sugar next time. Add anchovy earlier. Don’t skip the rest. That notebook is your commit log.
Branching: When You Try Something New
In version control, branching is what you do when you want to experiment without breaking the main project. You spin off a copy, try something risky, and either merge it back in or abandon it, all without touching the original.
Cooks do this constantly. Maybe you want to try a version with white wine instead of red. Or make it spicier for the friend coming to dinner who “likes heat.” So you ladle some into a smaller pot and experiment there.
In Git, you’d do this:
git checkout -b spicy-version
# now experimenting freely — the main sauce is untouched
If it works, you bring it back:
git checkout main
git merge spicy-version
If it doesn’t, you walk away. The original is still on the stove, low and slow, unbothered. And saving a cup of the base before you start experimenting? That’s git stash. Your flavors are now set safely aside.
Merge Conflicts: When Something Goes Wrong
In Git, a merge conflict happens when two versions of the same file have been changed in incompatible ways, and the system can’t reconcile them automatically. A human has to step in.
CONFLICT (content): Merge conflict in sauce.txt
Automatic merge failed; fix conflicts and then commit the result.
In a slow-cooked sauce, that’s the moment you over-salted it. Or reduced it too far. Or added the cream before the acid and now everything’s curdled and you’re standing in your kitchen at 7pm slightly panicked. Your vision and your pot are no longer in sync. You have to intervene. Add a potato to absorb the salt, thin it with stock, start negotiating.
Sometimes you can salvage it. Sometimes you reach for the base you set aside earlier and start from there:
git reset --hard e14a882
# back to the beginning. we try again.
Forks: Passing the Recipe On
Open-source software projects get forked all the time. Someone takes the existing code, copies it, and builds something entirely new on top of it. The original continues. So does the fork. They share a common ancestor but diverge from there.
When you share your recipe with a friend, you’re forking it. She’ll make it in a different kitchen, with different instincts, different adjustments. Her version will drift from yours over time. There will be different commits, different margin notes. Same origin story, different changelog.
On GitHub, a fork looks like this:
gigi/sunday-sauce ← original
clara/sunday-sauce ← forked, now evolving independently
Some family recipes have been forked across generations. Your grandmother’s Sunday sauce, your mother’s version, yours. All related, all distinct. A lineage of slow, careful iteration that no repository could fully hold.
The Real Point
What version control and a slow-cooked recipe share isn’t just a clever metaphor; it’s a philosophy rather. Both are built on the understanding that nothing is finished on the first try, that history matters, that you should always be able to trace how you got here, and that sometimes the best move is to go back two steps and adjust.
Both also require patience. You can’t rush merging a code branch. You can’t rush braising a curry stew.
And both, when tended carefully over time, produce something that feels like it could only have come from you.
Even if only one of them pairs well with a glass of wine.
References & Further Reading
∙ git commit → Git Documentation
∙ git log → Git Documentation
∙ git branch → Git Documentation
∙ git merge → Git Documentation
∙ git stash → Git Documentation
∙ git reset → Git Documentation
∙ Forking a repository → GitHub Documentation
 | A guest post by
|