Tech
Internals
Conf

Plan

My context

Atomic Flow

Benchmarks

Conclusion

gerold103

Types of projects

Types of projects

• Large size
• Complex processes
• Git - storage + CI/CD
• History is irrelevant

My context

My context

Specifics

C/C++: leaks, corruptions, thread races

My context

Learnings

Can not keep knowledge only in people. They leave.

Atomic Flow

Atomic Flow

Commit atomicity

Atomic Flow

Commit atomicity

Atomic Flow

Commit atomicity

commit d4e5f6g7

Author: Vlad Shp <example@dev.com>
 

        price: Discount for new customers
 
        Give them 10% as an entry bonus.

Instantly see "why"

Easy grasp what

Self-sufficient, self-explaining, brings value, nothing can be removed. Like functions.

Atomic Flow

Commit atomicity - Example 1

<Link>

Atomic Flow

Commit atomicity - Example 2

<Link>

Atomic Flow

Commit atomicity - Example 3

<Link>

1-line change

21-line explanation

Atomic Flow

Patchsets

Atomic Flow

Patchsets

Daily work is organized in patchsets

Atomic Flow

Patchsets - Example 1

<Link>

Small atomic commits with tests and explanation

Atomic Flow

Patchsets - Example 2

<Link>

25 commits

358 lines - the biggest commit

2400 lines total*

Atomic Flow

Patchsets - Example 3

<Link>

6 commits

6 lines - the feature

2800 lines total*

Atomic Flow

Linear history

Atomic Flow

Linear history

History is a straight line

Atomic Flow

Linear history - Pros

Atomic Flow

Linear history - Merge Hell

Based on latest master

Atomic Flow

Linear history - Merge Hell

Atomic Flow

Linear history - Merge Hell

Actual changes

Placeholders in history

Atomic Flow

Linear history - Merge Hell

Actual changes + conflict fixes

Atomic Flow

Linear history - Merge Hell

Atomic Flow

Linear history - Merge mitigation

Way 1 - Squash the commits

Atomic Flow

Linear history - Merge mitigation

Way 1 - Squash the commits

The source commits are joined into one

Atomic Flow

Linear history - Merge mitigation

Way 1 - Squash the commits

The source commits are joined into one

☑️ Simple

☑️ Linear history

⚠️ Low atomicity

Atomic Flow

Linear history - Merge mitigation

Way 2 - Rebase

Atomic Flow

Linear history - Merge mitigation

Way 2 - Rebase

Literally change the branch's base

Atomic Flow

Linear history - Merge mitigation

Way 2 - Rebase

Literally change the branch's base

Atomic Flow

Linear history - Merge mitigation

Way 2 - Rebase

Literally change the branch's base

☑️ Simple

☑️ Linear history

☑️ High atomicity

☑️ Small scope of conflicts

Atomic Flow

Linear history - Example 1

My project - a year ago

The lines - merge-commit tails with tombstone commits 😭

Atomic Flow

Linear history - Example 2

My project - now

Maximum 2 lines

Atomic Flow

Linear history - Example 3

Actual usecases

Tarantool
Database

• 💎 Ideal "Atomic Flow"
• ↩️ x 15 reverts in 4 years
• 🔎 Countless git-blame and git-bisect in <investigations>

Virtual Minds
AdTech

• 🔎 Frequent git-blame to investigate old code
• git-bisect + git-revert just recently for:
  • Perf ⚠️ in a library update
  • Perf ⚠️ in a feature
  • A bug 🐞 

Ubisoft

GameDev

• 📈 Daily investigations and reverts in "Perforce" version control system

Atomic Flow

Rebase

Atomic Flow

Rebase

Commits on a dev branch are rarely atomic from the start

Atomic Flow

Rebase

But they can be reordered ...

Atomic Flow

Rebase

..., edited, and squashed

Atomic Flow

Rebase

git rebase -i

Atomic Flow

Rebase

git rebase -i <base hash>

Your text editor

Atomic Flow

Rebase

git rebase -i <base hash>

Your text editor

Atomic Flow

Rebase

git rebase -i <base hash>

Your text editor

Atomic Flow

Rebase

git rebase -i <base hash>

Your text editor

Save

Benchmarks

Benchmarks

Method

Survey on Git usage

23 people: from juniors to CTOs

10 open questions

About atomicity, merging, rebasing, usefulness and harm of certain practices

Benchmarks

"Atomic Flow" takes ~10% of dev time.

But < 30 mins per task.

✅ When I first started making commits atomic, it took me 50% of my dev time. At this moment it takes me about 10% of my dev time.

⚠️ I usually don't keep my commits atomic, because it requires too much time, and sometimes there are commits like "wip", "without tests" etc.

✅ It doesn't take time, that's how I always work. Maybe 1%.

✅ Usually it is easy enough. Maybe about 10% of dev time is spent on rebasing and reorganizing commits, but there are many advantages.

⚠️ From zero for a simple bug fix, to 50%+ for a full-fledged feature, that exposes number of cross-component dependencies.

Benchmarks

✅ A huge impact on the maintainability of the product: track reasoning, bisecting, reverting etc.

⚠️ I think it brings a value in some environments. It is inconclusive to me.

✅ Structured change sets are a godsend to reviewers. It's particularly valuable for large refactoring changes, because it's easier to rule out accidental behavior changes or even introducing bugs as the code mutates.

⚠️ Commit granularity is important, but sometimes I feel like the project rules push my work back -- instead of simply merging something, I spend time working on commit messages and code style

 AF - 10% / 30min
overhead

"Atomic Flow" boosts the project.
Faster and better reviews and investigations.

Benchmarks

✅ I follow this approach, especially in my open source projects, and encourage PR authors / ask my team to follow it

⚠️ Does not matter in general, for large orgs with legacy code I believe it is not possible.

✅ Atomicity matters in large and long project, where employees come and go, and need a structured clear dev history + rules to quickly onboard new devs

⚠️ I don't care about atomicity, because no rule on that in the team

 AF - 10% / 30min
overhead

"Atomic Flow" is high value for "Product" project.
Low value for "Enterprise" and "Startup".

AF - boost project
dev

⚠️ My experience - pilot projects. Git is just a tracking instrument. 1 commit = 1 hypothesis.

✅ That's about ability to forget yourself and try to read your changes like somebody else, take the reader's seat.

Benchmarks

✅ Linear atomic commit history definitely provided a better experience for code review overall. It helps to complete review faster making it easier to understand.

⚠️ I think the main rule is that a commit mustn't be too large. It doesn't matter much if it's atomic or not.

✅ I think my review speed and quality increase about 5x when the commit change exibits atomicity and linearity.

⚠️ I don't know

 AF - 10% / 30min
overhead

"Atomic Flow" review is quantified to be faster 1.5 to 5 times
Due to how easy it is to read the patches.

AF - boost project
dev

⚠️ Does not matter for me much, number of unrelated changes and the overall size of a change do matter

✅ If changes are structurized in some way, it has much more chances to bring me understanding without additional communication over chat, calls and so on.

AF - high value for product

Benchmarks

⚠️ I always look at the full diff only. If there are commits like "lint fix", I think they should be squashed at merge

✅ I prefer a list of atomic commits and review them one by one

 AF - 10% / 30min
overhead

Half devs look at whole diff, half - at each commit when possible.
Some do both.

AF - boost project
dev

AF - high value for product

AF - faster review x1.5-5 times

✅ Atomic commits make reviews easier, faster, and more effective by providing clear, logical steps that build upon each other. Each commit tells a story: which makes reviews more intuitive. Commits like "fix typo", "fix review comments" e.g. spams history. Squashing these keeps things clean.

⚠️ Even when I review 'one by one' I still need to have a full picture - so I usually have an overview of the whole diff

Benchmarks

⚠️ Default git flow without strict rules about merging and rebasing

✅ Jira-task ID in commit messages, small and logically split commits. Pre-commit hooks for lint, format, and tests.

 AF - 10% / 30min
overhead

Linear history is better in every sense. People choose it when have a choice.
Varying in details like if merge-commits are needed.

AF - boost project
dev

AF - high value for product

AF - faster review x1.5-5 times

Reviews approaches vary a lot

✅ Always rebase, split into individual commits, support always-green master, 2 reviewers at least (to make it between three of you).

✅ I still (even with 1 long-lived branch) prefer to use the strict atomic commit structure. I believe it helps for maintenance and code support.

⚠️ I’d lean towards a Git Flow-inspired workflow, emphasizing on clean commit history and minimal merge commits.

⚠️ I usually go with relaxed approach - a dedicated branch for a task/issue with mandatory squash merge. So inside the branch anything goes, but after merging the PR it's just a single commit.

Benchmarks

⚠️ Never

✅ git blame is integrated in my IDE, I used it every day.

 AF - 10% / 30min
overhead

git-blame and git-bisect are used often.
Many use it daily or weekly.

AF - boost project
dev

AF - high value for product

AF - faster review x1.5-5 times

Reviews approaches vary a lot

Linear history is always nice

✅ Git blame — every day! It helps me understand who made a change and why. I also use git bisect (not daily, but I like it — it has helped me find a broken commit more than once)

✅ Of course I use git blame and git bisect extensively, they have helped me a ton of times.

⚠️ Bisect is rarely useful in complex projects and large monorepos

⚠️ I don't use them very often.

Benchmarks

⚠️ Sometimes they are helpful, cause I can find specific discussions, pipelines etc

✅ They are not useful. They just add noise and impair readability.

 AF - 10% / 30min
overhead

Merge-commits are inconvenient.
Hated by many, ignored by most, liked by few.

AF - boost project
dev

AF - high value for product

AF - faster review x1.5-5 times

Reviews approaches vary a lot

Linear history is always nice

git-blame and -bisect are cool

✅

✅ F***g s***y! How to f***g backport it?

⚠️ In large teams, constantly rebasing can be painful. Merge commits let you integrate changes without rewriting history. This requires less efforts but with rebasing, even though it needs a bit more time, makes things easier in the long run.

Benchmarks

 AF - 10% / 30min
overhead

AF - boost project
dev

AF - high value for product

AF - faster review x1.5-5 times

Reviews approaches vary a lot

Linear history is always nice

git-blame and -bisect are cool

Merge-commits are trash

Benchmarks

"Atomic Flow" takes ~10% of dev time.

But < 30 mins per task.

"Atomic Flow" boosts the project.
Faster and better reviews and investigations.

"Atomic Flow" is high value for "Product" project.

Low value for "Enterprise" and "Startup".

Half devs look at whole diff, half - at each commit when possible.
Some do both.

"Atomic Flow" review is quantified to be faster 1.5 to 5 times.

Due to how easy it is to read the patches.

Linear history is better in every sense. People choose it when have a choice.
Varying in details like if merge-commits are needed.

git-blame and git-bisect are used often.
Many use it daily or weekly.

Merge-commits are inconvenient.
Hated by many, ignored by most, liked by few.

Atomic Flow Summary

Atomic Flow Summary

Atomic Commits. The smallest logical unit. Nothing can be removed, nothing needs to be added.

Patchsets. Work on dev branches contains a sequence of atomic commits.

Linear history. Merge commits are eliminated or empty. Rebase before merge always.

Interactive rebase. The main universal tool in your "Atomic Flow" toolbox.

Conclusion

Conclusion

Atomic Flow

Focus on atomicity, history, reviews, longevity.

One Flow

Focus on simplicity, branch structure and linearity.

Git Flow

Focus on merging, branching, releases.

By Adam Ruka - see the wonderful article series.

By me - see this presentation and projects <one> and <two>.