Hello everyone, please welcome our next speaker, Vladislav, he will talk on efficient
to get work flow for high stakes projects.
One, one, checking the microphone, hello everyone, thank you for coming, a lot of great
people today who open source community, I absolutely love it.
So as was said, my name is Vlad, I am working in open source and appropriate proprietary
development for about 12 years already by now, time is flying.
And most of the time I spent working on databases, closed source open source, game development
and right now in advertisement technology and today I wanted to present you some strategies
of using Git that I found particularly helpful in my kind of work, in very specific conditions
in which I was working my entire career and I mean projects which are big, they live long
enough and it costs a lot to do anything wrong in them, that's why it's high stakes.
And I want to emphasize firstly, like this disclaimer, there is no one right way to do
Git, I am perfectly aware it's a very sensitive personal topic for a lot of people, what
is right, what is wrong and I do not claim my today's points to be the absolute truth,
it always depends on the project and even on people working on that project.
So I'm just presenting one of the ways that I found is very useful in my specific context
and I'm just hoping that you will keep an open mind, you maybe will try some of the stuff
I will be showing, it long have to take it all at once, it's not a complete, like
a modeling framework, you can just take some specific cheery pick, git cheery pick, some specific
points out of it which you will find interesting useful for yourself and just keep an open
mind.
So most beneficial my presentation will be by the way to firstly students, juniors who are in the
beginning of their career and they see a lot of ways to do version control, a lot of different
ways inside every tool and they like feel maybe a bit lost, what is right to do, which
tools are useful for what I hope, at least for Git, I can show you one of the ways which
I believe probably was how it was supposed to be used and also for senior and lead developers
as well who have pains in maintenance of their high stakes projects like to keep it clean.
Our presentation today will follow this plan, first I will present you my context, like
how it looks like, actually what I have to deal with every day, so maybe then you all
better understand why certain things I propose to do in a specific way, then I will present
you the points of my this efficient workflow, then I will show you benchmarks of git usage
in the end to see how what effects you can get when you get it applied in real project
with real people, like what people said when they try it what I propose and then we will
make a short conclusion, this QR code right now is this link will not work after the presentation
I will open it online and you will by the same link will be able to see it, so you can
as well say it now, I will also show it again in the end, so the ways of Git they obviously
highly depend on the type of project and people working on that project, there are like
maybe infinite number of projects and people were using them in different ways but I was
able I think to find free types which kind of allow to like almost every project you could
put into one of those free categories, roughly speaking, first one we can call like enterprise
it's usually something big, closed source, it might be not even in IT company like it
could be a bank or something like this and they have a lot of people, a lot of code, old
code, they have complicated processes how stuff is supposed to be done and they maybe use
Git for like hooks, CI, CD but that's all, otherwise Git for such projects, typically
from what I have seen is just a distributed code storage, they don't care if it's Git or
whatever else, as long as you can hook CI, CD on it, they are good for them, need this
to say that they don't care about Git history, clean cleanness of chemists or anything
like that, probably this will not be very beneficial for them, another type we could call
it a startup, it's similar to enterprise in a way that they also don't care too much about
Git history or chemists because they move fast, they throw things out like throw things
away, open, so keeping Git history doesn't make much sense, they will throw it away eventually
anyway and there isn't even much to keep since and you'll start up right, team a small
they are easily communicating with each other, a green one, things they don't need
the stick procedures again, here Git is more like a distributed code storage, the last
time though, it's a product, it's an open source, quite often, can also be closed source
but more often it's making sense for open source, where you have middle size project, middle
size team is not very frequently, chemists are being made like maybe at every hour on
hot days but unlikely more than that, and the project is much more, it tends to leave
long, it already leaves long, you can imagine like years, tens of years for more and it
is also high stakes, meaning that cost of mistakes is very expensive, financial and
repelational for the company, so you need to be very careful when you commit something
into such projects, it might affect actual clients who are paying to you and you're very
careful what you do, my talk is targeting the last one, the other ones might also find
that useful but from experience it's in enterprise, you sometimes just cannot do things
and start up they might not need those things but for product it will make all the sense,
before we proceed I will show you a bit a little bit glimpse into my context in which
I am operating, so it will be easier to for you a whole I hope to understand the following
things, firstly I write code exclusively CNC++ which means it's well firstly it's very fast
and nice low level fast company but yeah might be the short what I said, but also we do
have problems like especially C++ is hard to cook it right, you can cook it right but
it's very hard to do, one thousand different ways to do the same thing and you will have
all sorts of issues, a runtime which you need to take care of compiler will not help you
like memory leaks, data corruption, triads, racing, it's actually you need to keep to be
alert all the time, also code size will be starting from hundreds of thousands of lines of
code going over millions and really large projects and the code is old, my current code
base it's over 20 years old which means it contains every single C++ standard that
came out for all together, it's not like we're moving to next one they move all the
old stuff, it also means that authors of this code are gone like they're not there, you
can not ask them anything anymore, that's the main problem of the age of such project
and you have a lot of legacy, somebody did it, you don't know what it is, why, how it works
but it works, there is nobody to ask, and also call this high in every sense like it's
high load, it's high scale like large scale and it's high stakes, to give you an example
of high load like you add one byte to a struct, you think like it's not a big deal, it gets deployed
on one of the clients, they get explosion of hundreds of gigabytes in a cluster for one byte in one
structure or you add accidentally or you just decided it doesn't matter, code makes, it becomes
simpler, you add it like a hundred microseconds load down, one millisecond load down on a hot path
and then in the end of the month you will receive report from the client that every day during
that month you had a opportunity to cost because of that tens of thousands of euros per day,
this is what I mean as high stakes and high load, from all this I have concluded the two big
points, firstly you cannot rely on people because they will like in the short one they will
they will retire, they will burn out, they will be on vacation and suddenly you need to deal with
an incident and they are not responding or they like literally move on to the next world so
to say you cannot ask them, which means you need to rely on the code, code is the truth,
what is written and the code is what will be running, some people might even be in the team
and tell you what they think it's what how it's running but it might be not how it's running so
code is the only source of truth, you must rely on it, you must keep it clean so it's readable and
maintainable and story of that code so you can see how it was evolving and it will help you
in the future and all of those points will be presenting next I wanted to unite and there's some
catching name so it would not be just a bunch of like a pile of recommendations, I decided to call
a Tatonic Flow similar to like git flow, one flow, this is atomic flow, this is like we will start
with the most basic thing, it's most important point of my whole presentation, I show it first
so you are still not too tired by the end of the presentation, if you get just this thing right,
I will be already very happy and this third point is that commit should be atomic,
hence is the name of the flow, atomic flow, this consists of several things, what does it mean atomic?
In projects I work on, it's often very helpful when I can, for any line of code, tell why it was done,
the key point is why, not what, what is done, I see it's the code, code is what,
I can read it perfectly find myself, I don't need it narrated somewhere in the commit message
or in the comment, like LLM's write, like to use those narrative comments all over the place,
I need the why and the why, it's quite often noted in the code, for example why would we need it,
imagine, I know there is a bug somewhere in some function, somehow I know it's in one function
and then knowing the reason for the function's latest change, like in my case in 90% of cases,
I know there is a bug in a function, I open it's latest commit, I see the bug instantly,
like on review, maybe it was missed, you didn't know this was possible, then you deployed on
production, it breaks, you open the commit and you see I, yes, how, this is how it would break,
so I see the latest change and it gives me, can, can give me the, quite often, the answer, what
went wrong and it would also help me extremely much, if the commit is small, imagine you found
that commit, it touched the function like literally two lines of change and you like scroll through the
commit, that's it another thousand lines of change, some code being moved, some other features
being done, some bug fixes in the same commit, now you are not sure if this commit is at fault,
like if this place is at fault, maybe the problem is somewhere else in the same commit,
so it would be very helpful if this commit is small and is doing one thing in this one place,
then it's less cognitive load for me to understand the, notice the bug, those two things,
the ability to quickly see the why behind any change and the ability to understand that first
from its small scope form the atomic commit, atomic like it's also the name is kind of self-explaning,
right, the atomicity what does it mean in this case commit is self-sufficient, so it's alone,
this commit is already functional unit of your code, it's self-explaning, doesn't need any other
commits to be understandable, it brings value to the code and nothing can be removed from it without
breaking it and nothing needs to be added to keep it stable, so it's like an atom, a stable unit
of like your code evolution, it might still sound too abstract but think of it in another way,
think of commit as functions, commit's are actually functions because functions are doing what,
they take input, do something with it, produce output, commit does the same input of your commit as your
old code base, by the of the function is the div, name of the function, is git commit, git message,
and the title, output is the new version of your code and then it all makes sense, right,
functions are supposed to be small, do one logical thing, be self-sufficient and understandable
from their name, treat commits like this as well and then it's very easy to understand the reason why
it can be useful, let's see some examples, this is a commit, real one, do not read the small text,
I made it small intentionally, you don't need to read my slides, just look at, yeah, it also you can
click on this link when you get the slides to see the original commit, it will be available in all
examples, those links, so just pay attention to this, it's very small, it's like 11 lines of functional
changes and some text, it fixes one bug, a crash and it's clearly visible from the title,
then it does nothing else, explanation why, how did this bug happen, how did we miss it,
what was the reason it's in those two paragraphs of text, very nice, easy to review,
very clear to review and you'll also mention a stick at number, so if some context is not enough,
the person can open the ticket number and see some may be a discussion or a history of
older changes and times to fix it, can be very helpful, this was the previous version of the same commit,
which was rejected, because firstly, what is it doing like, is it a performance regression,
is it a crash fix, is it a logical issue being fixed, I have no idea, it says fix, what does it fix,
I don't understand, don't see pipe push like, what happens if I push, and the commit message is empty,
there is absolutely nothing and the commit is bigger, it has 15 lines, you know why,
because the person who created it, didn't want to write a test, and decided just in case
hack the same fix in multiple places, thinking that they might also break, but it was completely
unnecessary, the original real fix like it's actually even 10 lines, 11, 11 works, another example,
look at this mere chick quest, again you don't need to read everything, just look at the size,
it's 15 commits, it's doing one thing though, it's not 15 different things, it's 15 steps
of one, I think, in this case, bug fix, yes, and the average size of every commit is 50 lines,
so the all fix the same bug, those commits is just, there was one bug, which was manifesting
itself with multiple different places of the code base, unrelated places, but same bug,
and we decided to fix this in one virtual quest, in multiple small commits, every commit with a test,
fixes one place, the every commit is reviewable, deployable, and everything,
and this is easy to review, like one commit, 50 lines just do it for every commit, and they have
used them, if I would not care about commits, this would be over 1000 lines, which somebody would
have to review all at once, and spot their 7 different places which were fixed, this is quite
lot of work for review, including yourself, because first review you will be a self-review, obviously,
before you submit it to somebody else, another example, a bit extreme, but still interesting to look at,
it's one line change, 21 lines of explanation why this needs to be done,
the question is why not put it in the code, this comment in this case it's specific to that
commit, because this was a compilation fix, on the you can pileers, this bug didn't exist,
on old can pileers, it would not come by also, you kind of could not miss it, and this message
was for a review, really, not for the code maintenance, but still, it was very easy to review,
you don't even need to contact the person who wrote this commit, it's just all right there,
right in the text, from the commit, I miss it, you probably have already deduced that,
if you do it the way I proposed, then any non-trivial merge request will require more than one
can it, it's actually not very often when you can't get away with just single commit,
on something untrivial, quite often you will need to do, you will need to touch surrounding code,
prepare some base for your functional change, maybe move some code around, rename variables,
functions, extract, code from one function to multiple other functions, right there, this like
cleaning before you do the actual change, it can be actually extracted into separate committees,
and to work with that, when you introduce the next concept, the daily work must be organized
in so-called purchases or changes list or call it whatever you want,
usually when you do it like this, you do multiple commits from top of each other in the beginning,
which do the preparation, like some commits first, you will move code from one file to another,
some commits will do rename throughout the whole code base, some commit will add the flag to some
function and everywhere pass it as follows, so like in the next commit you can in some cases start
passing it as true, those kind of like preparatory changes, which have no functional value,
but they are needed to make the functional change later, this will firstly keep your,
obviously history clean, secondly it also incredibly helps on the review, because the reviewer
will be able to quickly go from the refactoring noise, it will be easy to review, right, you can
you could move like 5,000 lines of code from one file to another, you will review it like just scroll through,
or you even just look that the file names are okay, and then you don't need to look at the code,
which is moved completely unchanged, right, those large commits can be easy to review, or a commit
changes like 1,000 different lines, but all of them is a function rename, again the reviewer will just scroll
for those changes easy without spending too much cognitive effort on this, but then reviewer
issues the last commit, small functional atomic changes, and reviewer can spot issues in those changes
easier because they are smaller, it's less context to keep it in mind than you can notice issues
much easier, they will be more on the spot, but they will not be hiding in the huge pile of refactoring
noise, right, let's see some examples, again this one will already show, it's a merge request,
which fixes one bug in 7 different places, so it's 7 functional commits, small ones, and 8 commits,
do preparatory refactoring can benchmark, they're extremely easy to review, those other 8 commits,
it was like 50% of the complexity you cut away and make it very easy to review, and then the
reviewer reviewer becomes faster and higher quality, reviewer will easier find problems in your work,
and highlight them, this, imagine it would look like this, like you have commits, address,
merge request comments, review fixes, benefits the IP, all this stuff, it's unreviewable,
who are able to review the right side, will have to review it all at once, they will have no choice,
reviewing this crap, it's one by one, those commits are on the review under reviewable,
another example, also a bit extreme, but it shows the point well, it's 25 commits in one merge request,
2,400 lines of changes without even tests, with test it's twice more, it was a very large
single feature, which consists of multiple different parts, and on which I had to spend like a couple
of months, I think, but it was actually very easy to review, because you know what, every commit,
maximum was 350 lines, and more than half of the changes are refactoring, like preparatory changes,
which were also very easy to review, another example, the latest one, also I like it a lot because
shows how important it is to split code moves into separate commits, I heard the merge request
with 14 commits, 3,300 lines of C code changed, but 2,500 of them were one commit, where code was moved
unchanged, and reviewer can just go for that commit like in one minute, and then concentrate on
small 13 remaining commits, and actually it helped us to find a few issues which I fixed,
in the first round, I have to admit I was lazy, I did it in one commit, but then on review,
I was told like, no, you have to split it, and then yeah, it actually helped.
Technically, the previous points already make a huge difference, some people can even stop at that,
like you can just take commit that a missity, or you can take commit that a missity and patch sets,
but if you want more, there is actually more, which can help you even further, not even during
development, but already during deployments and incident investigations, and I propose to keep
Git history linear like one line. It means that when you look at Gitlog, or Gitlog is about
example, I always align, but when you build a Git graph like, or you use UI for Git like Gitcrack and
or whatever, you in projects sometimes see like there is a lot of parallel branches,
somehow intersecting with each other, right? I propose even in those UI's, let's keep our history clean,
one line. You still have development branches, don't take Gitmer on, like I don't suppose to
have one branch, like for instance, per force version control system, it has no branches, like
you do one commit and you need to merge it, there's no branches, but I still work on development
branches, but the main branch development develop main master whatever it's, one line.
You can even still have merge commits, it's just they will be also on the line, and they will be
empty by the way, because you will have no conflicts. Imagine it's possible, imagine it's easily
achievable. Let's see what we could get from that if it would be easily possible.
Firstly, each commit on the Gitlog line is going to be right where it was actually applied,
which is not like this when you use merge commits and you merge in your outdated branch into
a branch which went forward. And it gives you 100% possibility to see historically what changes preceded
which changes on your branch. The merge commits, it will not be so easily possible.
Like when you have a graph, you have two parallel branches, how can you say which one was applied
earlier, on the line it's 100% possible. You can also automatically from this, you can check out
Git checkout any point on the line, it will pass test, it will compile, it will be deployable,
and you know what it is going to be helpful for for Git by sect, you can get by sect even your
production release, like imagine you might release, you have two Git tags, and you know this new
release created a bug. Then you do Git by sect, type 1, type 2, you will find one commit which
introduced the bug, you can revert it first and peacefully fix it later. With merge commits again,
it will not be possible unless your history is linear. And then also coming from that, each commit
is going to be transferable. It's a relatively unique use case, but I do have it in my open source
project on which I am working on, but it's not mine. So we do have one long leaving branch,
master branch, we have multiple long leaving branches, one for every long maintenance release,
and we always commit to master first, and then we Git cherry pick to the other older releases where
this fix makes sense. And this is almost always gets applied without any conflicts, we like
literally have it automated in Git Hub CI. You can add a tag in our project like Backport version,
and the bot will cherry pick those commits and merge them automatically. You don't even need human
interaction if CI gets green, it gets merged. And this is because commits are atomic and transferable.
And last but not least is that it's less cognitive load, like developing life of a developer is
complicated enough. And we can simplify it a little bit at least in this case because you can think
of your project as a line as a sequence of versions. It's just easier to think than in terms of
graphs like which branch in parallel with which one was being developed and merged and so on.
I do hope it sounds nice to you as it does to me. And for that to work, we just need one thing.
Your branch is before the merge needs to be based on top of the target branch, like on the picture.
It is so when you do just just did Git checkout minus B, but eventually it will not be so,
because master will go forward, your branch becomes outdated and then like the most frequently used way
is that you click like you type Git merge, it cannot be merged, you have conflict, then you have
to resolve them and you still like Git merge continue, you do Git merge continue and then
what happens is that your commits, the metadata of the commits gets inserted into the history,
but the changes cannot be inserted into history. Your commits are not applied before some other
commits, the changes, they will be all applied on top in this one merge commit.
So, yeah, and you will also have to put all the conflict fixes in this merge commit.
So, if some of your commits were outdated, they will stay outdated in the history and conflict fixes
will be in the merge commit and it can be challenging to fix them all at once because
when you have imagine a very large merge request, many commits, you merge it and you have
multiple conflicts and multiple places of your patch, you will have to fix them all at once,
it might be challenging to do compared to if you had a chance to fix them independently for
every smaller commit. Also, you lose a commit or a miss it because your commits which you just merged
inserted into history, they are not atomic anymore because they do not work without conflict fixes
which are applied later in another commit. And finally, it's even unsafe to do that because when you
imagine you have master brands and your brands, master brands is like it went forward, it has changes
which your brands doesn't have. Your brands has changes that master doesn't have. Both of them can be
green CI. When you merge them, you get a field version which never was running CI, you cannot
be safely sure that it's safe to merge to deploy. So either you like risk it and merge it anyway
or you first merge master into your branch and then merge your branch into master and then you have
two merge commits. There are multiple solutions to that, at least two that I know, first is
squash the commits. It's actually a nice simple way and so it's even available in GitHub and GitLab at
least just like a checkbox and it will automatically squash your commits when you merge them into
master into one commit. Then you do have it's very simple, you have linear history, it's just a little bit
loss of the atomicity but still it's actually a nice simple way to get away with the linear history.
There is another way. The alternative is you need to somehow change the base of your commits.
So they are based on top of the latest master, right? Which means you need to re-based, change the base.
Imagine it was like this, it was outdated and then you change the base and it becomes
one line and then you can finally move it. It's called fast forward merge. So it's a merge,
still but it has no merge commit because it's not needed. There is no conflict. You can just
move your commits on top of the master branch and then it just works. The only problem here
is that you need to learn how to re-based but it's worth it. Like look at my project a couple of years ago.
This is a graph of my git log that I built of the project like it was in state two years ago
before we started using photomic flow. Every vertical line is a merge commit which was applied
later and then the tail goes down to the commits inserted into the history and then I was asking
people how can you work with that and there was one guy who was saying like oh I like it so much
it's so cool. I love merge commit and I was asking him like can you tell me what happened before
what in this and he could not. He's like oh just give me one second just one second and he opens his
git cracking UI and scrolls through all this hell. He couldn't tell me and I don't blame him because
I also cannot read it. It's machine readable maybe but it's I can not read it. And this is how it looks
now. It's a single line. We still have merge commit so I could not like completely destroy them.
We use them on release but otherwise all the development between two releases it's always
a line. Every commit compiles past a test it was at some point on a development branch but then
you merge it is one line. Our team like actually extremely happy right now they previously they
very much were like against it. They were resisting a lot but then eventually when they looked at
how I do it they started using git as well. Now nobody of our team wants to go back ever to this.
And some actual use cases where it helped like it's not just to keep things outestically nice and
beautiful but with no use it has actual uses like free projects which I am working on or
worked at. The freelance project where atomic flow comes from it's a trample database.
They don't even know that they sit on a gold mine like they invented atomic flow. They never
advertised it anywhere but I figured it's it's useful to show to people and the team did just
little bit of statistics 15. Geetrevert calls in last four years just clear geetrevert. No context
commits were in such clean state that you could pick a commit like a year ago
reverted deployed and it works to remove a bag or like whatever or some feature gets deprecated to just
reverted the feature or like sometimes daily sometimes at least weekly.
People create a commit where they reference one or two older commits as and saying like oh here we
do this fix because in some previous commit that was missed and they give a commit hers or like
you like sometimes your reference things or when you work on a feature you can reference previous
attempts to implement this feature in previous commits literally put get get hash in the commit
messes and some UI like GitHub get lab they can even make it clickable they will highlight it
and you can navigate it click by click to see the story of a certain feature or a certain bag
how it was evolving through multiple commits in time. At my current main job we started using
git blame almost daily because as I said we have very old code base we have multiple features
which we don't even know how they work. Nobody touched them like in literally 10 years. You open
some function it was not touched for 10 years. You have nobody to ask for. How it was done you
opened like git blame sometimes you are lucky there is a like ticket number or something. In the
fresh code you always use git blame and find something helpful and we use three simply git by
sect and git revert for two performance degradation rewards very quickly after deployment we were
able to find them with bisect and revert and various bugs in production and in development as
well. Like sometimes you develop a branch you see it's not passing tests you can get bisect
your own development branch to find in which commit you introduce the bug before you have in
the request area and also I worked at the game they have company where investigations using
like they don't use git they use per force but it has something similar to git by sect
git blame and there it was happening daily like every day team over 100 people somebody was using
it to find the reason for a bug or reference something for a new feature or whatever so the principles
they don't just buy just in git is just in git it's very nice to have branches but in per force
for example it also quite applicable so let's assume cleaner history at cool we wanted which means
we want three base and about that I wanted to talk slightly more most of what I agree today is usually
most I talked today is usually agreed with but people are afraid of rebase for some reason even
though it's easier than merge but it's worse when you make your branch you will not get a clean
history right away right you will your branch quite often will look like this like formatting fixed
part one VIP all the stuff and you want to make it nice like ideally you would want to reward
some things maybe squash them together and then suddenly you have a nice have nice commits you
will not get it from the start or like it will be very rare so you usually need to be find the way
to restructure your commits before submitting them for a review and rebase can also help you
even then because rebase it's not just changing the base rebase should is actually re-apply
rebase re-applies the commits on a base that you give it but this base can be anything it doesn't
even have to be another branch you know you can rebase your own branch on yourself on all itself
and for there is a command for that get the base minus i with which you can do quite a lot of stuff
for example take this dirty branch i do a base this branch on itself and minus i it means
interactive it will open text editor of your choice like nano beam or some lime vscode whatever you
can it's configurable where it will show you the plan of rebase every line means like the git
when even you save this file it will apply those commits pick means applying this case
but you can change this plan it's a text editor so you can reorder some lines you can change the
action like you can squash them commits you can change message of some of them you can stop in
between commits and add the new commit there you can delete some commits and then you save it and
git will apply this plan and you will get a nice branch there is obviously much more to say about
rebase i will not be saying more about this but i created tutorial which helps teams to learn rebase
when they never used it before by this link again it's clickable later on the slides for the
is link at the bottom where i created a project with a with a very dirty branch and instructions
how you can turn this branch into a diamond it will look very clean you just follow the steps
where i show you how you can reorder commits add new commits remove commits from the middle of your
branch and so on this was the entire background of atomic flow now a quick through the benchmarks
benchmarks here like i usually do technical presentations where i can benchmark things like
measure latency rps here it's very subjective because it's about people about processes but i
made a survey and i was asking people from different companies different titles what do they think
about specifics like of their daily work with git and starting from juniors to multiple city
who's open source close source project center price start apps products and this is what i
got i will show you a median opinion on every topic that i was a survey firstly how much does it
cost to do atomic flow some people reported like median 10% of development time they spend on
rebase and atomicity polishing but they sounded like a lot to me then i asked how much in minutes
people were able to quantify less than 30 minutes per task people who do it a long time already they say
like one five minutes per task it obviously depends on the size of the change but this is like
median answer it also was reported that atomic flow boosts the project development speed in general because
you might pay if you additional minus direct development but you get an incomparably faster and higher
quality reviews which means you will have less bugs less investigations faster investigations when
you are trapped because of linear history also atomic flow as expected was reported high value for
product but not so for enterprise and startup this is completely understandable as i said my way
is not the most right way is just one of the ways which seems suitable for some products which
reported it as high value then i was particularly interested in speed of reviews and people who
like i had project right now unique situation people were using old ways and switched to atomic
flow and i was asking them how do they feel about reviews now people quantify it all of them
quantified it as faster now but they quantified between one and half to five times faster because of
how much easier it becomes and then i was curious how people review stuff to master price some people
look at whole diff and then at individual commits some people look at individual commits then whole diff
some people do it just this way or just the other way but in the end basically like over 70% of
people do like to look at individual commits when they can also linear history was reported better
in every sense by the reason well when they have when when people have a choice like sometimes you
don't have a choice but people said they would like to use it when they can also to mice for prices
well get blame and get by sector peer to be quite popular tools because i thought always it's like
niche commands but no most of people i asked use them daily or weekly or at least try to use
then i was curious the use of merge commits several people unrelated to each other synchronously
reported to me the same word hate when they were describing how they what did they think about merge
commits this tells you how convenient they are so those are basically where where all the points
i was asking you can take a photo or something on this slide it's like a summary of the whole presentation
you can say to share it when you don't want to scroll for everything i will give you five more seconds
to take a photo then we move on one two three four five you can also likely trope in a
way by the QR code and the short summary again the atomic commits smallest logical unit nothing can
be removed navigate needs to be added patch sets on development branch you deal build a patch set you
sent a review a patch set no single large commit linear history just remove merge commits you will get linear
history as simple as that and interactive rebase is your daily tool to achieve in coldies
the conclusion there is no just atomic flow there is also other ways atomic flow today we focus on
atomicity history reviews and language of the history and project there is also one flow which is
what expired me to do this talk it's built by a guy Adam Ruka and he wrote like some many years ago
he wrote an article basically to summarize how much he hates merge commits and then it evolved in
a series of articles where he designed this one flow of using git it focuses more on simplicity
so prehorse squash for example branching structure like how many actual long-leaving branches
you're supposed to have for what atomic flow doesn't care about that how you should do releases
linearity of the changes and there is of course git flow which tries to do kind of everything
git once and this is why it's differently cooked everywhere this was the end thank you for
your attention again this QR code you can use later to open this presentation
you can connect with me on the like development then professional social networks and
youtube channel where I talk more about system programming, operating systems C and C++