← Reference notes

License: CC BY 2.0 Belgium. Source: https://archive.fosdem.org/2026/schedule/event/3VNNBK-efficient-git-for-high-stakes/

Summary

Vladislav Shpilevoy, speaking on the FOSDEM 2026 main track in Janson on 31 January 2026, presents one way of using Git that he calls Atomic Flow. He says there is no single right way, and that the right habits depend on the project and the people. He sketches three rough kinds of project. An enterprise, in his account, uses Git as distributed storage as long as CI and CD can be hooked up, and does not care about a clean history. A startup moves fast and throws work away, so a clean history pays less. A product, often open source, lives for years or tens of years, and a bad commit is expensive for paying clients and as a reputational cost for the company. The talk is aimed at that third kind, and at juniors who are lost among tools and at leads who maintain old code. His own setting, as he describes it, is large, old C and C++ codebases whose authors have left, so the code and the history of why it changed are what a later reader can still ask. An atomic commit is one logical change: small, self-contained, and explained by why rather than by a retelling of the diff. Nothing can be removed from it without breaking it, and nothing else has to be added to keep it stable. A rejected example in the talk is a bigger commit whose title was only "fix", whose message was empty, and which applied the same fix in several places. A patch set is several such commits on a development branch. Preparatory moves, renames, and flags come first. The functional change is a later, smaller commit, so a review does not hide the real edit inside a thousand-line diff. He wants the shared branch to stay one line. Rebase the work onto the latest target, then fast-forward. A merge of two branches that each passed CI can produce a result that never ran CI, and the conflict fixes land in the merge commit instead of in the commits they repair. Squashing on merge is the simpler route to a line, and it gives up the small commits. Interactive rebase is how he reorders, squashes, changes messages, and deletes commits while cleaning up a branch. He says a database project already worked this way without advertising it. The schedule page links the Tarantool repository as an example of the workflow in a high-stakes project. On his current team, git blame is what he uses when an old function has no author left to ask. A linear history is what makes bisect and revert useful when a bug has to be found and undone. A survey he showed on stage, which he calls subjective, reported a median of 10% of development time on rebase and atomicity polishing, and, when he asked for minutes, less than 30 minutes a task. People who had switched said reviews were from one and a half to five times faster. He also said that over 70% prefer to look at individual commits when they can. He names OneFlow, which the captions attribute to Adam Ruka, as a simpler model built around squash, long-lived branches, and releases. GitFlow, in his telling, tries to do everything and so gets cooked differently in every team. Captions garble commands and a few names. The survey figures and the workplace stories are his, not a study this note re-checked. This note follows the publisher captions.

Why it is here

Askers want to know what a commit is for, and how a history should look before a push. This talk is one maintainer's account of atomic commits, a patch set, rebase, and fast-forward, for a long-lived project where a bad change is expensive.

@misc{iil_note_vddekn6m,
  author = {{iinventedlight Library}},
  title = {{An Efficient Git Workflow For High-Stakes Projects}},
  howpublished = {iinventedlight Library},
  year = {2026},
  date = {2026-10-18},
  url = {https://iinventedlight.com/library/reference/talks/fosdem-2026-efficient-git-for-high-stakes/},
  note = {Permanent ID iil:note:vddekn6m. License: CC-BY-2.0. Summary of https://archive.fosdem.org/2026/schedule/event/3VNNBK-efficient-git-for-high-stakes/.},
}

For language models and agents: start at /llms.txt. This page in Markdown: /library/reference/talks/fosdem-2026-efficient-git-for-high-stakes.md.