 So I started developing Git in June 2006. I worked first a lot on Git bisect. And since about one year and a half ago, I've been working for GitLab and booking.com on Git. So I will talk in this presentation about how Git, and especially two Git commands, evolved. And what can be the benefits of using Git in what I consider a modern way, which is the way I and the Git and Linux communities feel things. So what do I call modern version control? So it's when it's easy to create and merge branches. So with subversion and CVS, for example, a branch is something big and important. You have basically a copy of all the source code for each branch on your machine. With Git, it's something trivial. It could be just a file with 40 characters in it on your machine. So it's much lighter. And why does it change everything? It's because as branches are much trivial, it's much easier to create a lot of them and to merge them. And in fact, the workflow that came from Git and GitHub and GitLab is to have feature branches, which is to have one branch for each feature of bug fix. And this leads to pull requests on GitHub or merge requests on GitLab, which are ways to manage how to merge branches and merge many of them. And it can lead to complex workflows like Gitflow, where you have many different branches like this. And when people see something like this, they can be like, wow, it's wonderful. It's really smart. I like it. They can be like, my god, it's too complex. How are we going to manage this? And in fact, these two reactions are not incompatible. You can have both. But you have to make a choice between either allowing a complex history or wanting to keep a linear history. So let's say that you want to keep a linear history. So you want a tool to linearize the history. And that's what Git rebase is good at. So this way, well, also with Git rebase minus i, the interactive rebase, you can also merge and move or remove commits, and it helps you manage a linear history. Now, if you allow a complex history, one of the problems you have is how to visualize it in the best possible way. So there are commands on the command line like this one with Git log minus minus, decorate minus minus, one line minus, minus graph. And you have tools, also great tools, to help you. Another problem is how to find the first bad commit when you have a regression, for example. If you have a linear history, it's quite simple. You just test between the last good version and the first bad version. You test in the middle, and depending if the bug is present, you test again in one part or the other part of the history. But when you have many branches, it's much complex to first know which commit is the best one to test, because it's difficult to find a middle, something that is in the middle. And also when you test, it's difficult to know which commit you can now skip for your next test. But you have Git bisect skip to help you. And if you want to automate that, you have Git bisect run to automate it. I cannot go into details for each command, but I will give links at the end that can help you. So for example, here, if you have a bug introduced by this commit, then all the descendants of this commit will have the bug. And Git bisect helps you find this commit B. So in the end, we will see that Git rebase and Git bisect work very well together. And we will see that by looking at code review and testing. So why it's interesting to look at code review and testing? It's because if you want to be agile or if you want to improve your quality, you have to do code review and testing. For example, if you want to be agile, you need your client to test often your software. And you don't want your client to test buggy software. So you need to have continuous integration and to test and code review a lot as part of this continuous integration. So what I consider a modern code review is when you polish your commits. So what I mean is that you rework your commits until it's clear that they are all good. And to do that, you have to do small commits. Otherwise, if a commit does too many things, it's difficult to review and to test and to see that it's doing the right thing. And also, you have to have good commit messages. That is commit messages that explain why you are doing these changes. And Git rebase minus I, the interactive rebase, can help you because it can help to split commits and to modify commits and their commit messages. Now let's talk about modern testing. What I call modern testing is when you have these four points. The first point is black box tests. So these days, unfortunately, when people think about tests, they think about unit tests. But if you have a big software and you test each part, even if each part individually works, it doesn't mean that when you put all the parts together, it will work. You might get integration problem and all kind of problems. And the bigger your software, the more important it is to test in a black box test way. But so in fact, that's what Git does. Git itself is test using a framework that test it in a black box way. Now the second point is to test each commit. That's because one bug introduced by one commit could be masked by a later commit. And so you could catch it when testing each commit. And also, unfortunately, GitHub and GitLab don't really encourage you to test each commit. They encourage you to test the commit that will be merged or the result of the merge. But that's not really enough, in my opinion, because testing each commit also encourages the developers to have consistent commits. And it's also important for code reviewing and testing. The third point is to have at least one test for each new feature. So why? First, because it shows that the feature has been at least tested. It documents a feature. It makes reviewers job easier. And it makes it easier to add more tests later. And also, the last point is to test to have a test for each bug, even if the bug is not fixed. It's a bit the same. It documents the bug. It helps reproducing it. And it makes sure the bug will not appear again. And it also makes reviewers job easier. And also, it's easy to do if you have already one test per feature, because you just have to copy the test and change it a little bit. And you should be good. Also, having one test for each bug, if you start doing that, you will find that you can have a much improved workflow by first writing a test for the bug even before you try to fix it. That's because if it's a regression, then you can use git bisect run with your test case to automatically find the first bug commit, that is the commit that introduced the bug. And if you do that, it will be much easier to fix the bug, because you will have a lot more information, and you will have to look at only one commit. And then you can commit the bug fix and the test together. And if you use such a workflow, then, of course, first, it's much easier to fix a bug. But also, you get accurate information from the third bad commit. And you take advantage of the small commits you have made and the good commit messages. And people who do that really have greatly improved their efficiency. For example, I don't know if you know how the Linux development cycle works, but there is a two week long merge release. And during that time, Linux merges something like 10,000 commits. And then there are RC releases, 7 or 8. And the goal of each release, one per week, the goal of each RC release is to try to fix as much bug and regressions as possible before and as many regressions as possible before releasing the new Linux kernel. And as Linux himself doesn't test much, it's tested by the maintainers. And you can imagine that without Git bisect, when you have a bug and you have to look where the bug could be in 10,000 commits, it's not really easy if you don't have Git bisect. So to conclude, I hope that you could get an idea of what could be modern source and version control with Git. And especially the evolution that it represents and the logic of this evolution and also an idea about what benefits you could get from this in terms of quality and agility. Many thanks to the Git and Linux communities for their help in my work and also to GitLab and to the Forza Asia organizer. And thank you to all of you. Maybe I have time for a few questions. No, we have 15 minutes till next talk. So yeah, there's time for questions or questions for Lars. Yeah, if people want to ask questions. I have no idea. So we have 10 minutes. So we have time. Would you mind moving into a little bit about rebase and bisect? About bisect? And rebase. Rebase. OK. Yeah, first I could talk about these links. So the first one is about my presentations. So there are presentations with details, especially about Git bisect. So this link is interesting also because this company, Semmler, develops some static analysis tools. And they have studied what happened after a company, one of their customers moved from another version control to Git and GitHub. And what they find in this study is that as their static analysis tool can count the number of bugs that are introduced every month, for example. It shows that just using Git and GitHub, for example, but I think it would be the same with GitLab or Bitbucket, decreases significantly the number of bugs that are introduced every month. So I think it's interesting if you want to move your company to Git. So this is the main website for Git. And also, this is a test framework written in shell that has been extracted from the Git test framework five years ago. So you can use the same test framework for your black box tests as Git using Charnes. And in fact, I am the maintainer for this. For this project. Yeah, and this helps you also install Charnes into your project. And this is a site called GitRave News about news about Git that I also work on. So yeah, about Git bisect, I don't have much in this presentation, unfortunately. But maybe I can try to show you from another presentation. So yeah, maybe is this one. Yeah. So this one is about Charnes, the test framework, and Git bisect. So the basic idea is to find the first bad commit here. And so all the red commits are called bad because they have the bad behavior. And the blue commits are called good. And of course, so the goal of Git bisect is to find the first bad commit. And it uses a kind of binary search algorithm, except it's not on a linear history. It's on a complex history. So you can start it like this. So you say Git bisect start. And then you give it the bad commit that is the first commit that has a bug with Git bisect bad and then the commit. And then you can give it the good commit with Git bisect good. And while in fact, you can give it many good commits. If you know that, for example, many previous releases did not have the bug, you do that. Or you can put everything on one line if you want. And after that, so this is an example, it tells you the number of revision left and the number of steps. And it automatically checks out the commit that you have to test. So that's when you use it in a manual way. So you will test on your own each commit and then tell it if the commit is good or bad. So for now, you can test. For example, you can run your test script or something. Or if it's a graphical application, you can use it and check if it has a bug. And if you find that it has a bug, you say Git bisect bad. And again, Git bisect checks out another commit that you have to test. And you repeat those steps, testing and saying bad or good until in the end, you get something like this which says the first bad commit is this one. And it gives the author, the date, the commit message, and the files that were changed. And at the end, you have to use Git bisect reset to go back to the branch where you started. So that was the manual way to use Git bisect. But you can use it automatically with Git bisect run. So in this, for example, one simple example is to bisect a broken build. So if you know that it doesn't build since this version, you can just say, good, this version, Git bisect bad, the current version. And then you say, Git bisect run make. And automatically, it will check out a commit, run make on it. And depending on the exit code of make, it will decide if it's good or bad, and then check out another commit, and so on, automatically. So for example, here, I used the same start command as before in the manual case. And here, I used Git bisect run with this. So this is a toy example. You should not, if you are looking for a string in commits, there are better ways to do it. But it's good to show how it works as an example. So here, it's just looking for this string in the make file of the Linux kernel. So it says that it runs the command, and then it checks out, and then it runs the command, and so on, automatically. And basically, it gives you the same output as before. And it says, Git bisect run success. So I could go, yeah, the way it works is basically, Git bisect run executes the command that you gave it. And depending on the exit code of the command, it can do many different things. So if the exit code is 0, the current commit is considered good. If it's between 1 and 127 except 125, it's considered bad. If it's 125, it's special. It skips the commit. So this is good, for example, if you are testing something, but you cannot test because you cannot compile, for example. If some commits don't compile, you cannot test. So in this case, you can say in the script you test to Git bisect run, make or exit 125, and automatically, if make fails, it will skip the current commit and find another one automatically. And yeah, if it's not one of those, it will stop bisection instantly because if you detect some too bad problems, this is a good way to stop everything right away to try to find what went wrong. The exit code of commands are only between 0 and 255 on most OS. If you give it minus 1, it will be something like 250. For example, if you do exit minus 1 in C, it will give an exit code of 255 or 254. So yeah, I could go on if you want, but I'm not sure it's interesting for everyone. So do you want me to go on with how bisect works? Yeah? OK. OK, so yeah, I told you about Git bisect skip. So the problem is that, for example, when some commits don't build, when it doesn't compile, often you have a string of commits that doesn't compile. And then this commit, for example, fixed the compile problem. But if the bug you are looking for has been introduced by one of these commits that doesn't compile, Git bisect cannot tell you much about this. So in this case, it will say something like this. It will say the first bad commit could be any one of these, for example. Because as it's not possible to compile, it cannot do much more. But there are ways to try to, OK, so I have to stop. Sorry. Thank you, everyone, again.