[Inaudible],

Of course we have to start with a big thank you to RingCentral. Ringcentral developers allows you to revolutionize the way your business communicates with APIs for voice, SMS, team messaging meetings. And with that I'll go ahead and pass it on to Pauline. All right. Thanks again, thanks for joining. And let's get legit. Okay. But before I do just a little bit of an intro about what I do. So, Mmm. So as I mentioned, I'm bombing and I work at their school and in Cipro where basically a subsidiary of home advisor, which is a marketplace for homeowners and a service professionals to meet. So let's say you need your garden done or your house renovated, you could go on there and you'll find a service professional to do it for you. So we're the Dutch branch to that basically. And I'm a software engineer in the engineer.

So yeah, we're based in Amsterdam active in Italy, Holland and France. And that's about [inaudible]. So without further ado, let's see if this is you. So is this you when you're trying to work with gets, because when I started out and for actually no, pretty long while after I started out, this was me. Cause first can be very frustrating, but I promise you after today, after some of the things I tell you today, they'll take some getting used to. But I promise you when, when we're done and when you get used to it, you're, you can go from this state to this state, which is obviously the lead hacker mode that every developers, buyers too. Mmm. Where your fingers are just dancing over the keyboard and you feel like you can do anything. It's like playing the piano almost. Now that sounds like an ideal world, but I promise you it's possible.

And the basis of Oh, all of that I found in, that's all my commits. Now, if you haven't heard of atomic commits yet, they're basically what the, what the word implies. So if you'd look at the word atomic, if you think about what atomic means, it means something so small that you can divide it. So you can apply that to your commits. Make your commits so small that you can cancel by them. So when applied to commence, it's [inaudible] Mets basically I think boil down to three features. So the first thing that a commit needs to be to be atomic is that it's a single irreducible units. That's the atomic there. So every commit must pertain to one fix or feature, nothing else. So as you can see on left, there's a commit there that says little sign up feature refactored language class.

And then it says this commit holds the entire sign of future controller or positories templates as set up masterclass names. Some are factoring too. So I went in and did that, that while I was there. So there's all these different things going on in there. And then on the right side you can see that they're split up into different things. First you see, if you start from the bottom first you see a refactor the mater class, then create the user entity and the repositories, all the persistent stuff. And then finally the endpoints. So you've got these three small commits all doing one thing. Then the second point is that everything has to work. So that means your application behaves as it as you expect it to. Doesn't break tests, all are all green and obviously everything is covered by tests. Okay? Lastly, they have to be clear and concise, which is to say that the purpose must be clear from the commit message and the description.

Now that already automatically becomes a lot easier if you keep the 0.1 where you have that single irreducible unit because you don't have a committee that goes this and this and this and this because you have a commit where only one thing happens. You can keep the message really simple and concise and just go, this is what I did done. So that sounds really simple because it's just the three things. And the concept is kind of simple, but it will help you with a lot of things in your workflow. So that's what we're kind of, you're going to talk about. And the rest of the presentation is all the things atomic commits can help you with. First of all, it'll help you with keeping your sanity. And that's a big one obviously as we've seen before. Now imagine this scenario [inaudible] you branch off, you start working.

There's a story ranch or a feature branch and then there's a task that you start working on. So you branch off from that branch and your teammate is working on another part of that feature. So they also branch off from the same branch. Then they were finished with their tasks. So they push they made a, a pull request or a merchant request and it got merged in. So now you are base ranch is updated and you need those changes. So you can have, you can do two things, one of two things. So the first thing is you can pull, you just pulled up banks, branches your own branch, and then you get emerge commit because you merge all the changes into your match. And then there's the other option and that's free basing, which means you basically make it so that your your own branch as if it's just been checked out from that other branch.

So you make the base branch the base again. I know that's a little bit vague. I'm doing all these hand gestures. You're to amplify my point, but I forget that you can't see them. Anyway, let's go back to kind of the basics of what merge member base are. So we'll a get merged. You have your yellow branch is the base bench, so that feature of servants that is talking about before, and then you branch off into your blue branch, that's the task branch here. And then you have your own three commits and the base branch has three new commits that you don't have. So when you pull it and you merge, get them, creates one merge commit, merging the changes together, you get to resolve any conflicts that might occur and that's it. Then you're done. So that's pretty simple. So it's a, it's a one step thing.

The only problem is that it's not very good for your history because they're theirs. Mmm. When you go merge something, it doesn't really tell you what it's merged, what parts of the code is it's touched. Also there's changes from all these different commits in one place. That should really be in those comments. So it's, it's a little bit messy. And also as an added bonus of annoyance, anytime this base branch gets updated, you have to create more and more of these March permits polluting your history. So then comparing to get rebase, you have your, a bass brim Shyanne yeah. All these new commits, and then you have your task branch. Now when you rebate, again, it's like, it's like you've just done a fresh checkout from the other branch. So how good does that is it's replaced all your commits and compares to the Delta at that point in time.

And if there's any conflicts at that point in time, you get to resolve them at that point in time. And then it rewrites your commenced. So under the hood it throws away your old commit and makes a new commit with the exact same message and everything. So it looks like it's the same commit. So all the changes that were made are still in the same place that they're supposed to be. And your, your history is rewritten so that those changes are in, in your French. But your your messages and your context, her comment stays intact. So that doesn't pollute your history with all these strange [inaudible] of what you don't, you're not really sure what it does. And you can still have a really good overview of your, your history. Again, see what exactly what happened to, at which point in time, the problem is with get a rebase that if you don't use the Tallman commence, this is what's going to happen.

Now why is that? I say if you don't use atomic commits, and by that I mean, but a lot of people when they start using gets they using it in a way that's very natural to us and that is by checkpoint commits. And I say that's natural as office because it's very reminiscent of, for instance, when you're typing in a word document and you're typing away and you realize that you haven't saved in like half an hour and you're like, Oh, if word crashes now I lose all my progress. So I saved. And then you type a little bit more. And then you say the same with the video game. You make some progress and you're like, well, if I don't reach a checkpoint now and I lose all my progress. So that's, that's how a lot of people use get as well. This linear checkpoints based commence a flow.

But the thing is that's ideally not really how it should be used because it's supposed to be like a source of control thing. Right. So, but that's where it's told my commits basically come in. But if you don't use those atomic commits and you tried to do rebase, which is what I started to do when I first learned about re-base and people didn't explain to me how like we're supposed to use it and that it only works with atomic commits. I was doing those checkpoint Cummins and the problem is because [inaudible] each check my commit, you keep touching the same area of code because your changes that you're doing are spread out over these different commits. You're not organizing your committee. So when get replays, those commence and keeps checking the Delta, it'll keep running into the same conflict over and over and over again. So it'll have to stay solving the same complex over and over and over again. So bottom line is get rebates, in my opinion, is a better option both. If you're not going to use atomic commits, there's really no point doing it because if you don't, that will make you very, very frustrated. I got stuck for literal hours on your base because of this reason. And then you ended up with something like [inaudible].

This is from a website called commit logs from last night, which is basically a feed of random profanity. That's like crawled from politic repositories just like filtered by random profanity. It's a, it's pretty entertaining, but obviously you don't want this in your application history by the way, if you see those QR codes this is I've, I've put those anywhere in the, in the talk where I, I feel like you might want to check it out later cause there's more resources there. Oh. Whereas the interesting articles so yeah, obviously this is just a joke one, but then the rest of them are useful, I promise. So again, you don't really want this degree history. And that's the next thing. It's all my commits are going for him history. Because ideally you want clean surgical history. You want to be able to see exactly what's happened, at which point in time to your history, you want your history to be, to capture the capture of your application in a stable state so that you can comfortably revert to any point in time.

You just go back and be confident that your application works. And another added bonus that some people use is they use their, get the history to generate change logs automatically. So that's all pretty nice stuff. You can't really have that without atomic commits. So again, going back to those checkpoint commits before you might, if you use those, you might end up with a history like this. So starting from the bottom, you'll see that there is a commit that says fixed small bug. So there was a bug and you fix it and then you made a commit and then you realized you broke something else while trying to fix the book. So then you fixed whatever you you broke and then you create another, when you say fix the fix, cause that's the best you can think of at that point. Okay. So then you're done.

You create your PR or an MRI and there's requests for changes. So you go ahead and you it address the comments that were given and you go, okay, well what should I call this? Adjust comments I guess. And then you commit that and so on and so on. What really, if you look at this there's a couple of problems with this. There's, in most of these commits, the application is captured it in an unstable state. So you can never just go back to any random point in history and be confident that your application works. The history doesn't really tell you anything either. Like now in the scope of this VR, you kind of figure out what's happening, right? But outside of the scope of this PR, when it's merged in, you can see address comments and you're like, [inaudible] what comments? Well, what's the code at the commons?

Whereabouts? What part of the coin have you actually touched? So yeah, history wise it doesn't really work. And ideally, well what you want it to convey and what you wanted to do initially is fix the bug. So ideally you'd just have [inaudible] smoke meth, but how can you do that if you've already made the commitment? Well that brings us to our first command. This is probably the simplest one. A lot of you will probably already know it, but let's, let's go ahead and just show lists, demo it. So you can see, I do get log in, there's two commits. Now I just make a small change and then you see there's unstaged changes there you go and stages. And then I just go get commit dash dash amend or dash, a aim for shorts. And then it gives you the opportunity to change the message and it just opens here.

Text editor. So in my case it's been, but it could be nano or whatever. It just opens in your text editor. It's those little file ads. You just write whatever you want and then you save the file and that's your [inaudible] amended. So you've rewritten the history. The only issue with this though is that when you push it, because you've rewritten history, it makes a new commit hash and your origins gonna think, Hey, hang on a minute, I don't have this committee. I had another committee here with a different hat. So it's going to complain that it doesn't belong there. We're going to have to force push and that sounds really scary, but I promise you it's not. So we'll get back to that later then. Okay, so this is pretty easy. Now you've amended this one. Commit Bryce all in that one. It meant that you needed it.

Yeah, but what if you get comments and those comments are thing from before things in separate commits. Let's say it's like the last two commits, then amend is not going to work because you can only amend your, your last minute and that's where interactive rebase comes in. Okay. So we already talked about rebates and then interactive or base is the dash I option just gives you, it's the same thing. It just replays all the, all your commence, but then also gives you a little bit more control. So that dash I gives you some options and you don't always have to rebase onto a different branch. You can also over base on your own wrench. So if you do an interactive or base onto your own branch, it'll look like this. We'll be getting rebased dash I had head tilty and then however many minutes you want to go back [inaudible] and there's a few ways of saying the same command, but I always do it this way.

So when you were based on your own ranch, it means you're just going to replay the commits on your own breath bench rice [inaudible] dash I, like I said before, it will give you a little bit more control over how your rebates. So it will present you with this little menu at the top you'll see the four commits that you want to go back and then there are prefixed with pink. And then there's a little menu below the menu is actually recently expanded it. There's a few more options there now and a newer version. Yeah. And we'll just go through a few of these. Just really quickly, we'll just go through this list. So there's pic which is already there before each commit. It's just use the replay, the commit as usual, don't have anything with us. Then ours reword where you get the little text file and you can reword your commit message.

Then E for edits. It gives you basically the most control cause it just, it just checks out that committed completely and you can make changes to it. You can amend it, all of that stuff. And then squash is, you take the committees, you take two commits and the committable low is going to squash stove United merged. Well yeah, squash kind of covers it. I'm into the, the one above it. And then you can still change the message and it's like a combined commit message and fixed up does the same except quicker. Because what it does is it just merges them together and just takes the one it takes the commit message from the first one automatically. An X for execute is really interesting because you can run any commands that you want on that comment. So let's say you want to make sure that all your tests are green officer Mitt, or you want to run your linter or whatever, you can give it the X command and you're C Lachman and then the, and then it'll run that over that commit.

And then D is for drop is just dropped the entire committee. That means all your changes are lost. It's not reset, it's just completely removed. So the way you give these commands is just to a, again, this is just your text editor, so it's just a file that you can edit and you just replace the pig [inaudible] whatever commands you want to use. So we'll just go through what the edit one looks like. So you'll see your add some onstage changes or I'm going to go stash it. And then I go into my interactive rebase and I'm going to go back five commits. So you see the five commits and let's say I want to edit the first one and the fourth one. So it'll check up the first one. I'm going to apply my stash. So there's my changes again. Then I can just add that and stage it.

And when I go get rebase dash dash continue, it'll act like an amends. So it will open the message again. You can change it. And then when you write the file, it'll keep going. So it'll replay all those other commits and then stop at the four again because you wanted to edit that so you're gonna make some more changes. I'll see the changes are there, adding it and then continuing it. And then you've rewritten your history. So that's how you can, okay. Do that trick on more than one commitment back in your history. And you can keep your commits lean that way and you can make sure that all the changes that you make afterwards are still in the appropriate commits that they belonged. Okay. Another surprising thing that becomes a lot easier when you use atomic commence [inaudible] Oh, to review. So when I first started out, I'm did those checkpoint commits when I went to code review to do a coder view, I just click the files change tab in a get hub and get that as the same.

So I just went to the FOS change cause I was just like, I just want to see the changed files. Right. the problem is with those change files, you'll see that there's 30 of them. There are no particular order, there is no context other than what's in the PR descriptions. So you get a lot of information overload. You don't really, no what you're reviewing very well, especially once you hit the fifth or the sixth file and you still have 25 to go. So the quality of your review goes down as well. I always used to get that problem where, you know, when you're reading a book and halfway down the page, you realize you just zoned out and just kept reading and you're like, I didn't actually pay attention, so I have to go back again. Just reread the page three times before you finally get it.

That's what I had was my code reviews. But now using atomic minutes, I a review committee, I admit. So you see all the commits you know, just listen, listen. And then that just commands clear or just open it in a new tab, opening each in a new tab and just go, go through them one by one. Now the reason you can't do that if you're not, it's on the commence. If you're not moving atomic commits. [inaudible] I should rephrase. You can do it. But it's annoying because if you're doing those checkpoint commits and you start out with the first minute and you comment on something and then you're, you know, you get to the third or fourth commit and you realize, Oh, the thing that I just request to change is on, it was already fixing the third or fourth. So it doesn't really make sense.

So I refuse to commit by commit. But when you're doing atomic commits, you have these nice, like little encapsulated commits that do one thing and they have a very clear message and they're just divided up into more palatable chunks. So, and not only makes it more all of use to you and it makes it easier for you to review, but your review also gets a lot more thorough. So every before I said with the files changed, you, you only get the context of the the PR description. Now you get the, with each commit, you get the the context in the message and the description. So this is how I write commit messages. There's a lot of different strategies for making commit messages. There's things like [inaudible], you know, prefixing your I'm subject line with the issue number. I'm not a huge fan of that because like when you migrate issue trackers, those issue numbers aren't going to be relevant anymore for instance.

But it's, it's not a huge deal. There's also something like get Moji where your, your team decides on difference meanings for emoji. Like, Oh, this emoji means it's a bug or bug fix. [inaudible] Emoji means it's a feature. This emoji means this or that. And so you prefix the subject line with that emoji and then at a glance it's obvious what you're looking at. That's also pretty cute. We don't use it. But the general consensus is that there is a couple of guidelines to just make. So just to set a standard, the most important thing is that you just have a standard with your team. But the guidelines are kind of like this and you'll notice I have another QR code and I genuinely think the the article linked there, that's a really w a good article and it's very widely spread.

So I definitely recommend checking that out. There's also a bunch of stuff in there that you won't discuss today. So the first, the first guideline is separate the subject from the body with a blank line. I'll get back to why that's handy as well. It's, it might not be as obvious as, so as I think what we'll get back to that. And the second thing is limit the subject lines of 50 characters just to force you to make it short and concise and just more readable. Then capitalize the subject line. I guess that's just a set the standard to be honest. Yeah, do not end the subject line with the period. That's also just I guess to set a standard. But also it saves you the character then use the imperative mood in the subject line, which is to say that you, for instance, don't say fixed past tense, this thing, maids, blah, blah, blah.

You, you say everything in the Paris imperative moves. So you go fix boats, add blah creates controller for instance. And it's just, it becomes a bit more, obviously it saves characters as well. But it also becomes a little bit more clear just to read it. It just becomes more easily readable because it's more direct then a wrap the body at 72 characters. Now this does actually have a technical historical reason as I've been told, but also just wrapping the body at some point is important because I don't know if you've ever seen someone who was just created a [inaudible], just a really long description in the body and didn't wrap the lines and then they create a PR for instance, and then you go into get dub or whatever you use and you have to side scroll, like horizontal scroll all the way for one line.

And then at some point you have to go all the way back again. It's super annoying. So wrap the body because then it just becomes a little readable little fool square. Okay. It really does make a difference. And then use the body to explain the, what the live versus the how. So this is a thing that it's kind of, it's like an elusive thing for a lot of people. To kind of like understand, and this is what a lot of people argue about as well. Well what I mean by this is use the body to explain the what and the why versus the how. As in don't explain the how, focus on the what and why. And what I do is I use the subject line to say what's I did so add feature at, well that's the terrible subject, but like [inaudible] controller for this net and then the body is the wine.

I'm like, why did we feel the need to make this change? That's what's important for the message. Because that house should already be in like the how is like the technical details that that will become apparent from the changes. So that's not relevant for the message. So, Mmm. Let's look at some examples. And this will also show you why the blank Lang is important between the subject line and the body. So if you look at the, on the left, you get your get log and you, you see the create user entity and repository. So it says in the subject line, it says, well, what it does, number blank line. And then it says the Y now on the right side. So you get the whole context. They're not on the right side. I use this one a lot. It's just get logged dash dash one line and that just chooses the subject line.

And now it also makes sense why you should [inaudible] limit your subject line to 50 characters and use a blank a line in between. Because if you don't do that, your subject line might be cut off and you won't have everything you need in the, in the one-line view. So that makes sense. Now you might think, okay, wrap the body is 72 characters, fine. Limit your subject line to 50 characters. Fine. But like, what am I supposed to do? Am I just supposed to go in there and manually count every time I ride a line in my description? Well, good news. You don't have to because there's this thing, Oh, I should've added the URL. Just take a photo. Maybe I can, yeah, I'll treat the Euro later. If you for some reason can't use the QR code because this, this will lead you to this.

But I good friend Louis and it'll have some bash configuration and some of them configuration that will add some nice colors at get auto communication, stuff like that. And it'll tell you when your subject line is too long and it will automatically Europe, the bodies of these two characters. No, I didn't need everything that's in his configuration files. So I've just like changed it to my needs. But there's some super handy stuff in there. Yeah, no. Aside from all there that there's some quick wins that you can get from from using a [inaudible]. The first one is sure, a big name because let's say you're a, your teammate is working in parallel to you and you don't need all the changes in our branch. You just need the one commit now because your teammate has also, that's another thing I should mention.

If you're doing atomic commits but your teammates aren't, it's not going to work. You all need to like set of standards. Do you use atomic meds? So that being said, I'm assuming your entire team is using atomic commence. You can just go ahead and go into their branch, pick just the commitment that you need, and then it has all the changes that pertains to that commit. So you won't need to like [inaudible] three or four commits that all Tufts the same thing. And that all tried to achieve the same goal because you have it wrapped up into that one nice little package that you can just pick up and drop into grown branch. So that's super easy. Okay. Mmm. This how it goes. This is their ranch. Let's say this is the commit I want. So I'm going to go back to my own ranch and then I'll just go get a walk, get logs.

So there's two commits there and I'm going to go get Sherry dash. Okay. And I copy or I paste the hash looking at that I wanted. And then if you do get log, you'll see there, but there's three commits now. And so the other committees avid, so is then you can drop stuff easily. You might've already seen that drop in the legend for the interactive rebase before. Mmm. The reason you can drop stuff really easily with atomic commits is again because it's not coupled to anything else your commit will only be doing one thing. So if you need to drop that one thing, you don't have to manually go back into the code and undo everything that you did. You just like dropped that commit and it's all gone and it's not tied to anything else, so it won't break anything. So this scenario happens to me a lot when for instance, I'm a, I'm making things Mmm.

PHP seven proof where I, I've noticed that there's no strict typing in a certain class or whatever that I'm touching. So I'm like, okay, I'm just going to add strict typing to this. Mmm. Yeah. So I'll do the strict typing thing in a separate commit. You just go like out of strict typing or whatever. Well, in the imperative mood, add strict, strict typing to this and this class. And then I'll go, I'll continue on whatever I was doing before. And then, okay, what sometimes happens is you it goes into production, something's not covered very well. Or there's like a method call somewhere that's not using the correct type, but it was never caught because it was, it was never strictly typed. So now stuff breaks. So now you need to go back and be able to go like Ooh it broke. And just like remove only that and not the other stuff that I was working on. Cause if it was in the one commit I would have to manually go in and remove all that strict typing that cost like probably like 10 to 15 times longer than just dropping it. So I'll just show you how to do that.

So you have to get log and then you'll have this, but you want to remove [inaudible] let's say that's the strict typing thing. We'll go get every day stash. I Mmm yeah, totally for sure. And we want to remove that commit. You can just cut the commit, delete the document. So just one more time, cause there was that legend right, that had the drop command. You don't even have to use that command. You can literally just delete the line. Okay. It will be gone. So I'm not even entirely sure whether commend is there, cause you can just do this. So that's how easy it is. It's even easier than it looks. Now the next thing is a binary or give by sex, almost give it away. Goodbye sex. So that's another big one that people are always a little bit intimidated by it. Nobody really knows what it means.

So you might wonder why I put an egg emoji. And that's because get by sex. A bisect stands for binary search, binary search, pretty easy to explain you like a bunch of eggs and the building. So let's say you have a building and you have a bunch of Eddings and for some reason you want to figure out what the first floor is. Where are you drop an egg and a breaks. Let's say in this hypothetical, completely unrealistic situation. It takes like four or five floors until a neck drops that you want to figure out which one is the first one. So one way to go about it would be to start from the bottom through drop one, it doesn't break. So then you go into the next floor, you dropped one, it still doesn't break. Then the next one and the next one. And so finally do your breaks.

So this time it took five times. But let's say this building is 50 stories high. It only breaks on the 49. There is that chance, you know, and you might be lucky and realistically you would be lucky. Mmm. Cause it would probably break on the ground floor it. But if you're not lucky, it might be really time consuming for you to figure out what floor. What you're looking for. So by, by research is basically this, you start in the middle and you know that it breaks there. So then you can already to do stuff like between there and the ground floor or somewhere is the first floor that your egg will break on. So then you start in the middle of that and then you know that it doesn't break. So then you know, it's in between there. And the first first [inaudible] that it broke from.

Yeah. So then you go in the middle of that and then it breaks. So now you know that it's that for, and it took you way less tries. And you can imagine that the building was 50 stories. This would be so much quicker than to just go floor by floor by floor. So you can do the same thing with your application and your commence. And again, it's all my commence, make this much easier because you can just go back to any point in time and you know exactly what happened at that point in time. And you can be reasonably reasonably confident that when you checkout at that point in time, you can run your application, you can test like where things broke or where, where it's not behaving the way you thought it should. So, let's see. Let's take the example of for instance, a button that was always 20 pixels from the right.

And now all of a sudden it's like, Oh, a hundred pixels from the right. And you're like, hang on, when did this happen? So I know that like two months ago it was okay, and now I look at the application today and now all of a sudden it's so somewhere in between there, something went wrong. So that's where I get my sex comes in. So we're going to do that by research. This one's a little bit quick so I might repeat it but because it's also a little bit overwhelmed [inaudible] so you start your bisects, give us a start, then you Mark the point in time that you knew was good. See that's already too quick. Sorry about that. So you start your goodbye sex. You already know that hash of the last good point. So you go get buy sex, good that hash.

Now you take your last commitment because you know that one's bad. So you marked that as bad. Get my sec bad cash. Now it checks out the middle of that and you run your application, you see that the button is where it's supposed to be. So go get buy sex. Go ahead. Then it checks out in the middle of that and then you go, Oh, this is where it was bad. And then eventually you've gone through all the things that you had to do. So then you go get my sex resets and it'll just spit out the [inaudible] the the commitment that you're looking for. So again, this is a really short example, but let's say there's, you know, if it was two months ago, there's like there could easily be like 150 minutes. So you don't want to check out every commit and see where it happens.

When you can say probably that would probably take you like five iterations or something I haven't done. Please don't quote me on that. Okay. I haven't done the math, but anyway, it'll save you a lot of time probably. So before we go to question time, there's a few points of skepticism that I had when someone came into my team. Okay. Few years ago and got me onto what's on my commits. So I asked him all these questions to start off with. So before you asked me those questions, let's just, let's just see if you already had one of these. So, bye Pauline. How do I call people out on the streets? Because you're rewriting your pistol. So that example from before where we were like, Aw, fix, fix the fix. Mmm. You could see that someone did something wrong in the first committed. And then when you rebase it, there's only that first commence.

So it looks like they never broken anything. So you can't do that anymore. But then really, if you think about it, what is the purpose of your source control? The purpose of your source control is to control your source, which means, in my opinion, it means that it's more [inaudible] really control how your application behaves and that you can really be confident that it behaves a certain way. You can go back and forth and you have a really clear history, clear overview of everything that happened. So I think that's a lot more important than being able to go like, huh, you did this at this very specific point in time because also, no, forget. Yeah. Never rebase mastering you. Only you only clean up your own branches. Then the history that's on masters, I have final history. So at that point you can still see everything that happens [inaudible] when not on people's personal branches.

So I don't think that's very important. So yeah, I always make the comparison with the book. You'll always read the last edition number book. You don't need an outdated edition of a book with [inaudible] that information and compare it all the pages and go, huh, I knew there was a typo somewhere. You don't do that. You just want the most relevant information to. Right. So that's how I see your application history as well. Okay. Oh this is a big one obviously. How will this affect my flow? Because very basic thing and stuff is nice, but it looks a little time consuming. Sometimes you just want to, especially on a Friday night or I've ever done stuff and now there's beers at the office or you have to run or something. You just have to like, you just want to commit. I make the one checkpoint.

Yeah, push it so that if you get sick on Monday, someone else can pick it up or whatever. And you don't want to like spend a lot of time cleaning up your history, being, putting everything in the proper place. And that's actually fine. I do that all the time. I do that at least once a day. At the end of my day. The thing is you only have to really make sure it's cleaned up before you prepare to like go and merge it. So in that respect, there is a difference between your five and your public branches. So your private ranches are the ones that you are working on by yourself. You never work on one branch with two or more people that anytime someone needs your man's, just tell them like, check out a new branch. You're mansion is your private ranch and you can make that as messy as you want, as long as you clean up later before it goes into your public branches with the shared history and all that.

None of these be clean. But before that, it doesn't matter. So my private branches are always very messy. And I always clean it up afterwards and this is how I do it. So let's say it's that Friday and I have that huge checkpoint commit. [inaudible]. Okay, so there's a massive commit for a day's work. This is my regular cleanup and slow. So I go get recent 10 had [inaudible]. So that's resetting the, the last commitment that I made. And you see all the changes there. You see that there is a [inaudible] let me just go back really quick Zach. I want to point out the changes that were unstaged. So we're going to reset it again and you'll see the changes or like there was a handler, there was a bug fix and then there's two files that our relevance of feature X somehow. So I'm going to add my handler changes and just add it to the last commit because I can see that that consensus commit is about the handler. Then the changes that are left are bug fix fix and the two files that were modified that have some things to do with feature X. So we're going to add the feature X-Files, Oh, the X files. And then not anyway. And then they're staged. And then you make a temporary commitment, ugly commitment. So it just doesn't matter. It kicks me dash and feature X temporary permit. And then you do the same with the book of fix fix thing.

There you go. So now you have those two temporary permits. Now when we go into our interactive rebates and you'll see those too, two temporary commits there, that other handlers stuff was already the Hendrick man. I'm going to cut paste feature X after the commitment about feature X and the bug clicks one after the one about the BookFlix. I'm going to changeF yeah, pick intoF for fix up. And then it's mostly as those commits into the one that they were originally intended to be in. And then that's cleaned up. And that's actually like two minutes. So you can be gross with your history of all you want as long as you clean up later. And as you can see, once we get the hang of it, it doesn't have to take very long at all. And there's a few ways of doing this step.

If you're, if, if you're if you're going to be here for the York's stop, they'll be giving, we're going to go true a few ways of doing this. Okay. That may or may not be more comfortable for you when you can then just try them all out and then pick one that's a [inaudible] most suited for you. Then the big one isn't enforced. Pushing is scary cause you, when you force bullshit override your origin. So essentially you can override things that you really don't want to lose. No, I would say yes. Force bushing is scary if you do it. So your public branches, if you're forced pushing to your own private branches, that's only your changes are overriding. This is also another reason why I never worked on one branch, on a shared branch with anyone else. I'm only dealing with my own changes that I'm forced pushing too.

And if I'm really worried about overriding stuff, I can just locally that got a copy of my own friends somewhere. But this basically never happens. Also, even when you forced the posts, you can use get rough logs to like go back in time and fix all your mistakes again. That will be covered in the workshops. So that's a little more advanced. We can't really get into it now. The only reason, fourth question can be scary is if you haven't protected your important wrenches. So let's say master, you'll have to protect it. I see you're a master. Manage before was pushing. There's never a reason to ever push. It's a master. Everything that goes into master, it has to be merged in there. As far as I'm concerned, we actually have to have the situation at a place I used to work at where we hadn't, yeah.

Protected or master ranch, which not smart. And then someone started working and she forgot, she just forgot to check out of a fresh brands branch. So she, she was just working for like a good while. I didn't realize she never checked out. She knew she was supposed to. But like sometimes people just get distracted and they think they've already done it. They don't check. And then she made the mistake and then that was that master over in. Now luckily there was quite a few people working morning in that company's still, there was pretty recent fresh checkouts of or checkouts based on masters. So we could just like force push that to there and then everything was fine. Well obviously that's [inaudible] [inaudible] what you want to be able to do. So protect your master branch and then also protect your developers because anyone can make this up a mistake.

They just haven't slept very well or anything. Yeah. So none. Mmm, that's, that's that. It's a time for your questions actually one more thing because I think the screen is going to be taken over for the questions. I'm not sure. Here's a bonus because people have been asking me after the talk like, Oh yeah, some sort of resource where you can go through the commands again. This is my cheat sheet. It's based on the talk. So there you go. That's it. You can take it over now. Hmm. Thank you so much for that awesome presentation. I know, hold on. We do have a question here. How do you perform on a descent way? Bug fixes to version one. I'll see we have package version one point X and version two point X. But how do you perform on a descent way? Wait, so you're saying like there's a, there's a [inaudible] or wait, you've already released it to one X, but there's still a bug on the one point X you got there. Okay. Yeah. So as soon as you do or release that site, that's, that's sad. Like that's your, you don't rewrite that history anymore. So you would just like create a bug fix and then a release that bug fixed with the new release.