Grokking git by managing kivitendo
CC Attribution - NonCommercial 2.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Büren, Jan
maintaining a oss project with git - kivitendo git for individiual extensions Deploying the free OSS project kivitendo and customising this with the power of git. We will use the power of rebase for long term satisfaction. We grok some basics of git: ······························ Speaker: Jan Büren Event: FrOSCon 2014 by the Free and Open Source Software Conference (FrOSCon) e.V.
 Okay, so this lecture is Grocking Git by Managing Kievi-Tendall. Grocking is slang English for understanding something really by doing it. This is an unknown English word, yes, warp. What we'll do is, I'll explain some things on a big point, on a big picture of Git, and then we'll see how we use it in our open source project, which is named Kievi-Tendall. Just for the question over there, so Kievi-Tendall is a double accounting system, is a web application, and it's a fork of Alex's office, which was a fork of SQL lecture. But it's not so really important, it's only the important that you can make bookings, and you can create invoices. And you can customize invoices, and that's where we use some Git branching and so on and so forth. If you have any questions, maybe my English is too bad, or something more like on a logical point, just raise your hand and ask questions. So far everyone is fine and knows what is going on. It looks good. I see many bright eyes. All right. So in British English, Git is a synonym for idiot. That's a good joking start, and because of that, it was written by Linus Thorwitz, and he said he is an egoistical bastard, and he names all his projects after himself, and that's why he named the project idiot. And actually, this is, if you don't know it, it's the source versioning system for the Linux kernel, and the history of that was Linus used a commercial system named Bitkeeper, and everyone was mocking around, ah, ah, ah, it's not open source, and then he said, okay, I cannot use it for free anymore, because Bitkeeper is not giving it me anymore for free, so I will just stop writing code for the kernel. I just write my own versioning system, and he named it Git. Well, so because it's a synonym for idiot, I thought it fits me. Because I usually forget stuff I write, so back in time, and I need something to keep track of, and something to remind me, and with most of the bullet points here are commonly known to every kind of versioning system, but some kind, some points are easier in Git, or anyway, it's quite hard to change history in Git, because every commit is unique, that's some major advantage of Git, and yeah, the main point for me is it does not forget anything, so I do. I can easily find everything I have done or others have done. You can break stuff, but it's easy to not break it if you know some common concepts, and everyone can do anything that is distributed, so clone is a full backup. I have quite a good synonym for this, it's like having a linear game, you have to choose, you have to solve, and at some kind, you just make safe games to solve it, and if you write code, you have a multiplayer game, and in Git you have every safe game of every player, and you can make a copy of every safe game from every player who ever played that game. So this is quite a powerful image to consider, and this was quite the true. Anyway, we won't go that deep into the system, but I will just give you three major ideas where we can use this for project extensions, because that's just to get something to grasp. So if you just Google, yeah, Git is better than X, because it has all this stuff, you can easily just Google this by yourself, this was my first hit I got when I just Googled why Git is better. The slides will be online also, so. And I pick one point, I pick any workflow just to give you one idea why this is better than any other systems, or you can implement many workflows, you can implement a centralized server workflow like in subversion, in subversion you just have one server, and you have many developers who just have to synchronize with the server, and they have to fetch and pull every time to the server. And if the server breaks or something, it's where the versioning systems is not in sync anymore and the project may delay, so the development may delay. So this is one workflow you can use, and just to give you the idea, you can even define the depth workflows where you have some master like dinosaurs who can only access to the repository, and he just gives someone else the lieutenant person access to some more developers, and here is a quality QA, and he does the next QA and then it will be in the server branch. So this is more or less one complex kind you can make, you can see that developer named N, he seems to be better than developer 2 because he can check into Linus repository directly and so on, you can define such a workflow with it as well. So this is some theoretical stuff, now I go to the point, we use Git for our web-based application QVTendo, and we have a project on GitHub, and we have release candidates and beta and stable versions, and they've been managed by a timeline just on GitHub, and we have the centralized server approach so everyone can commit, like five persons, and if something goes boom, then usually some other developer just rewrote it or they communicate via IRC or whatever. So this is our case in our Git versioning system. Sorry, I forgot to ask, so I have no clue, so on what kind of level are you into Git, he's always nodding, so he seems to be, he agrees with me, that's fine, so is anyone using Git right now? Okay, and that's got two. Okay, and you use it for your own project or for contribute to some open source projects or what do you do? Or it's also on GitHub? Okay. Okay. The project on GitHub. Okay, we can give some advice on that point, I postpone the answer. And I'll just give you the information, before we use Git, we also use subversion, and this was fine for me because subversion with this approach is okay, and if it's just somewhere on a server in a company, that's fine, but Git gives me far more options, more power in my feeling, and you can do some things with Git, you cannot do with subversion. I will show some, I will make some stuff with rebasing, I'm quite sure you cannot do this with subversion, so not so comfortably. Okay, now for some basic stuff. So I will, yeah, we go into the practical approach, we will just clone our project, I prepared some stuff live, let's see if this works. And then we go on. Oh, sorry, no one can see this. Okay, so now I just do a simple Git clone without write access, so this is... Okay, this is a Perl project, so we have some Perl files and so on and so forth, and I now have all the commits and everything which is in the major release line, which is posted on GitHub, and which is actually the full working developer release. So the next thing I, I will see. So what do I do next? I check Git log, like in subversion, you can see the last commit here, and what happens. So if you use Git tag, you can see what kind of major releases are there. So this is... And where is Git? So this is the current branch, you can see on what branch you are, this is actually the current master, so we haven't created the local branch yet. Okay, everyone follows so far, it's quite basic stuff, okay. So what's the purpose right now? If I have a client and I want to do a new project, it's best to start not with a developer branch. So, but we do not, actually we just install using everything with Git, so we just check out the latest stable release, and I just do a branch then. Okay. So, let's see. Okay. So now I checked out the release 3.0, we are in a somewhat detached state, so we are not on the current branch. No, it's okay for you. Okay, thank you. So we are, okay, I checked out this release, so we are in detached head, we can check with the branch. So we are detached from release 3.3, so here we are, and then we just create a new branch with this. Can we call it new? So now we have to create a local branch named toFroscon. What I want is that the rest theory is in that branch. So we- We have to give branch. Yes. Yes. That was my question. Yeah. So we have a new local branch. Where there are a few visit. No, no. This is my- Tell me a new master. Yes. With a new name. Yes. No, it's not- I'll just wait one. Give me 30 seconds. I go back to the slides and then it'll be probably more clear. Okay. So we have a new branch. The last commit is from 2012. Actually, the last commit from the release 3.00. And so what I did here, if we check on branch. Then we have- We are- This indicates we are on this branch. And we are in the version named text 3.00. To make it more clear. I can switch branches right now. So okay. This is now the branch master. We are on that branch. We check with get log. We are in 2014. This is the last commit right now. So this is actually the full clone from the- from GitHub. Okay. This is the commit message. There was a typo in some translation. Okay. This is a commit hash. This is unique. And this is a commit messages and the commit date and so on. Okay. As you can see all the text. Okay. Okay. Now we have created our own local branch. We have a specific release. So from that point we can start to do something individual. From the project on a stable release. And this is quite- This is actually quite convenient. Because I now can always cherry pick from the master if I want to. And do whatever kind of modifications. So usually- So the point here is if I just check out the master. Without creating a branch. If I just modify some stuff like modifying templates or whatever kind I need for the project. This will- I cannot commit them because I don't want them in the major release. I don't want customized templates in the major on GitHub. And that's why I created a branch. Everyone with me so far. I have some slides as well too. Okay. I changed- I already did this because this is a full installation of QVTendo. So this is configured from the back server locally. So we can see if we change something for the real process. No. It's just for convenience. Just to see usually- Anyway, the permissions are on VBV data. So just for the web server and so on. And you actually adjust- Modified some stuff. You need to modify some permissions. And so that is working. So I already did this because this has nothing to do with Git at all. We did this. We cloned. Anyway, it's always the same. You cloned completely from GitHub or whatever kind. And then you see text. You can see the slots where you are. And then you check out specific versions. If it's text, then you can see. And then you check out a new branch. And then you can do a branch. And then you have- Everything is prepared that you only work in your local branch without disturbing anyone else, even if you commit. So that's the point here. Okay, now there are three cases. If I modify the source, what may happen? If I upgrade to the next version, my extents may never conflict, always conflict, or may not conflict. Anyone knows what I'm talking about here? Anyone? Other way around? Any questions? Okay, let's see. What's the case? Never conflict? Do you surface with perfect measurements and get them onto a branch or something? Ah, no. No, no, no. You modify something in your working directory and it will never conflict. Yes, that's a good- Everything that needs not to be maintained via versioning system, that's usually dead-possessing. And in my case, in custom templates or themes. If you have themes, you can add your own themes and so on. You are not really, you won't check them into GitHub. In a more common way, it's everything which is not under version control in your repo, means that everything, every directory or every file which is not known to Git. How can we make a file known to Git? We use Git at. Let's see. If you don't know if you use, so you can check. Okay, you can check if you have anything that you are not checked in with Git status minus 0 and if you just use Git status minus U, you can see, okay, I have a template directory named Frostcon which is not committed. So in this template, there are some latex print templates for invoices. These are customized. So this is a new directory and they are not in the main repository. Let's check. Let's see. Okay, so this is actually the application. This is a branch in that specific version. It's a bit cumbersome right now. Anyway, I just add some stuff. Now we have a PDF. This is created by a latex. The latex templates are in the Frostcon template directory and they are out of the box. So more or less from the GitHub. What we see here is this is some identity stuff and here's a logo. I would like to customize this for Frostcon right now. Now we have something to commit. What I do first is I add the current directory to my local branch. Then I make this... I just change some metadata right now. Whatever this ifo. Okay, that'll be enough right now. Now we check. Okay, here it is. I like to visualize my commits right now. I use VI from my favorite editor. I just make an extension to use VimDiff so I can visualize what I did or what's the difference between the original file and the next one. So it's easier for my mind. I changed this command, this template command company to another company. So that's fine for me so I'm quite sure I want to commit that. So now I have made Git commit. Just I typed in the entire template here and you can see what's new here. This is everything is new because I just added this and there's one div, the identity from the template system. So that's fine with me. I just give it a commit message. Okay, so we have made our first commit in our branch. We can see this with Git log. So this is the last commit on the release 3.0 and here's my first commit on that branch for this customer project. And I changed the identity of the company. And this is case one. It may never conflict because we added a new sub directory for the template system. Well, in this case for the print template system for the invoice and this will never conflict. So this is now totally safe to be there. It has a unique commit hash and that's it. I skipped the point. Okay, we can replace logo and whatever kind of stuff we want. So the next case. Okay, it may never conflict. We had that case. The next case is it will always conflict. Can anyone think of a case what will always conflict? Although it will always conflict if I upgrade to the next version. It's a bit tricky. Any idea? I take bad ideas. I take any hint. Okay, this will always conflict. Yes, sure. Okay, if I delete files, it will always conflict. No, but I just also some. Now, I always conflict in this case. There is, for example, there's a version just a hard coded information which will change every release. Like change log, for example, in our case because in every release we make a new change log. So we always conflict and there's a version file just like in Debian, ETC version. We have that case also and this is a 3.0.0. We just make a new version here and this will always conflict because it's, as a best practice, always to set up a new version number if I take a new release and if I modify that file, it will always conflict. So this case really depends on the project or what your release management is doing. And yeah, okay, and the next case is may conflict, what's that? Yeah, exactly. So all project source files I modify which are already there and I, yeah, in that case many files. Okay. I get to the point. Let's see. Yes, we do that. Okay, here is my version file. You can see a 3.0.0. my customer wants to have his own project version, I just add minus cross-con. OK, that's done. You can see with Git status, I have changed files here. I commit that file, send it to Git. Done. If I check my log, I can see OK. This was the next commit. This commit will always conflict. If I do a rebase or emerging against the next stable version, and now for some modification in some source files. Let's see. I pick. Where's my? OK. I pick a report on customers. OK. So here are default checkboxes right now. I want to disable telephone and mail. So anyway, my customer, my client gives me a call. Oh, I hate this report, because everywhere I click on next, I always see telephone and email. And no one is filling that data in our case. Please make a change to GitHub and remove those checked box because we don't need them. So this is we have a customer or a client who says, OK, I don't need that. And sometimes it's like, OK, everyone else in the world should have my opinion on this kind of checkboxes or on this kind of report. And so the easy case is then, OK, I have a project branch or a customer branch. And then they can say, OK, for you in the project branch, I disable the checkboxes. That's fine. I have for the commit. That's OK. And I have a branch. And it's fine for me then. So this is the cheapest solution to get the project going. It's something to do with marketing and so on and so forth. And we'll do that. This is also a template file. But this is maintained by JIT. Sorry. Too lazy to write. OK, this is a HTML template system named Clue. So we are here, in the report, in the report, in the report, including the report here. OK. It should be the next year. Oh, no, it's just falling that way. OK, I have the HTML text here. I just removed the checked. Let's see if I edited the right file. OK, so it's gone. OK. So I got my contact. And let's go this. Oh, yes, email is set. OK, we check. OK, I usually use GetDiff to see what I did. OK. OK, you can't really see. But you can guess. OK, that line is changed. Let's contact phone. And email. If you scroll. Now, this is the case in the original version here. So checked, still active. And in my modification, it's gone. This is just for me. So I always use GetDiff to be double safe. I only edit the kind of stuff I want to edit and modify and also do and check on the web applications if I just call you right. For the graphical output? For the graphical output? OK. OK, now I have that also committed. And, yeah, so all my commits are there. I have three cases. Never conflict, it may conflict, and it will definitely conflict. OK, what will happen next? So the project is done. So the minimum customization is over. So what will probably the next thing to happen? It's already checked in. OK, let's say I'm on a server where the customer is using this. It's locally checked in. So it's on my project server, and it's checked in on that. And the customer is happy. He doesn't see those checkbox there. He has his own version number. He can, where we alter some more identical stuff, like changing logo and so on and so forth, that's done. So what will happen next? That's no. No, I don't know. I just keep those changes in my local branch. So I don't want to, I can also push this branch to GitHub, but it doesn't make sense. Well, it doesn't make sense for the customer project. If it's not a real benefit for the project in general, I do not push this back to GitHub. Yeah, OK. Yeah, usually the server will be back there anyway. So this is fine. If I want to back up this, yeah, just on one note, on one server, this will be, but this is another case. So that's fine. That's fine for the customer and fine for me. If we'll be backed up in the normal backup procedure, and that's fine. Yes. Well, he will work with the project, and after one or two years, he will find out, OK, there is a new release. And the new release has feature X and that cool feature. And he really needs a new version. And so what do we do now? OK, I just visualized this. This was the last commit on 3.0.0. This is a 2012 commit from the release 3.0. And the yellow commits are my branches, branch commits. And two years later, I completely forget the old extensions, and the customer wants to upgrade safely to the current version. Luckily, I have a project branch with Git. And what I always do, and I find very convenient, and I don't know if you do that, I rebase against master. And this is like I check out the master, I make a pull from the GitHub, and then I check out and go back to my local branch, and then I rebase against master. So did anyone do this before rebasing? You did. OK, you usually merge. Or did anyone merge with Git? Yeah, OK, merge is here. OK, that's the main advantage of rebasing it. This is visualized here, that if you merge, in subversion, you merge at a specific point of time back in history. So after the merge is done, you cannot see what was the original intent of the commit. Because if there is some more modification on the same file, it will move back entirely. It will, like on an ecological type of saying, it will go deeper in the ground. You have to dig harder and harder. And if you rebase, the concept is different. Because all the branch will be put on the current head you are rebasing against. There's a major advantage here. So right now, if you merge this, let's say it was in 2012. So I do make a merge against the current version. So I have to integrate this commit in my branch against the current version. And then everything goes on top of that state. Yes? And if you rebase, it's the other way around. So he skips all the branch, Git, and then just goes to the 2014 version, to the current version. And then he revines. He will remind my own branch against the current head. So this means all this commits will be put on top at the exactly point of time I'm right in. This is a major advantage. So the hash keys will be all the hash identifier is still there. And my original commits are also there. So if it conflicts, it's usually easier to see where the conflict is. And it's a bit more convenient on a graphical point of view. If you have some graphical stuff of your versioning system, you just see, OK, this is all the customers. It's extension. They are replayed after the upgrade for the next version. We see that in practice right now. OK, anyone remembers the commands I had on the slide? So what was the first thing to do? No, there was one step before. So we haven't touched this project for two years. So first we check out our master. And we pull against the current repo. So now we get all the commits from two years against the major release. We have them in master with commits and unique hashes. OK, that's the first step. Now if the customer is now used to this, it won't work anyway. So we are now in some undefined state without the customer extensions. And we have the current version. We can see we are on master. We can easily check back to the branch here. We are still in the 3.0 version. Everything's fine. But we just pulled the master to get all the commits and all the actual changes from the last two years. OK, next step. Which one? Yeah, OK, Frostconn. Yes. OK, and now? Yeah, yes. OK, what will probably happen? We have three cases. Yeah, at least one. So we may get two. And with the. So. Why not the repo release? OK, you can do this also. But this is a bit difficult. If I do against the actual current release, I make a new branch with the release name. And then I can rebase against the actual release. Yeah, you are definitely right. No, you would just to cut it short, so you would do an extra step there. You would create a new branch with a current version, just to be sure. Or sometimes it's not necessary. It depends on the state of the developer. So the developer is fine. So we checked that. With a customer, we were based against master with the current developer system. OK. And that's. So we see we have a conflict. And we'll use. OK, so what's here? What the? The current hat. So this is the developer version. So the version file is at 3.10 unstable. This is that box. We can see our modification on the branch. This is a Frostconn branch right here. And we can see what was there before we did that modification. And on that box, my editor, we will decide what to do with this conflict. So any ideas what to do? Yeah, great. OK, this means there is a here's a, I don't know, this is a conflict right now. And that point, I need to look at. OK, yes, your project is now in 3.1 customer. We have a new release only made for you. Great. And that's fine. Everyone with me so far? OK, that's right now the developer. That was on a change. That was before the change. And that's how I get there, integrate, and decide to handle this conflict. Quit on. OK, now he said, I forgot. I said, git rebase me, minus, minus, continue. I guess it's wrong. OK, and that's it. Yeah, sometimes you have to do them. Perhaps this is already, let's see what's the look. That's OK. In that case, we didn't need that. Sometimes you have to do this. I'm not quite sure when this is the case. Maybe it's only because of one line, I don't know. But right now, this is a latest developer commit. And you can see it's not a merge. He did that, our commits after the last pulled master commit. OK, we had no conflict here because it was conflict-free. For a question change, it was a case where it had to be a conflict, and the default report is still working. And so there was no change in that version. OK. OK, just as a reminder, we checked off master, we pulled. Actually, we have to always pull. And here we can do another branch with a release tag whatever, and then we check out our local branch, and then we rebase against master or the current stable, whatever kind of commit where we want to rebase it. And if we, OK, this is not, if you want to use a visual itch, you can use git k, if this is not known. So this is the output from git k. We can change this also. You can see this is our, here's the latest commit. We rebased. And you can see here is the master. We, the point of commit where we rebased again, and you can see we have three commits which I did here, live here, added to those branch. OK, so we have that here. Just to be complete, so my git config use, which was not explained in this live demo. This is the RLE-ST just to use git diff. You can configure whatever editor you want to have. And you need to have some names and emails just to do commit with git anyway. And best online tutorial work is played. I found right now, in short of time, was that one. He had this analogy with using safe games, and it's a multiplayer game, and everyone plays around the world, and they get all the safe games from everyone. This was quite a nice analogy. So if you want to dig deeper into that, use that. And if you, whenever you do at least some tiny custom modifications for a project, just take those half hour extra time to make a branch, and to commit against this branch, and best case with git. And then you have for safe, perhaps a lot of brain cycles here to use later if you cannot remember what I changed for that customer or at that point of time. OK, great. So that's what made a major point. Yeah, then thanks to you. Thanks for your time. And questions? We'll see you tomorrow.
 Okay, so this lecture is Grocking Git by Managing Kievi-Tendall.  Grocking is slang English for understanding something really by doing it.  This is an unknown English word, yes, warp.  What we'll do is, I'll explain some things on a big point, on a big picture of Git, and  then we'll see how we use it in our open source project, which is named Kievi-Tendall.  Just for the question over there, so Kievi-Tendall is a double accounting system, is a web application,  and it's a fork of Alex's office, which was a fork of SQL lecture.  But it's not so really important, it's only the important that you can make bookings, and  you can create invoices.  And you can customize invoices, and that's where we use some Git branching and so on  and so forth.  If you have any questions, maybe my English is too bad, or something more like on a logical  point, just raise your hand and ask questions.  So far everyone is fine and knows what is going on.  It looks good.  I see many bright eyes.  All right.  So in British English, Git is a synonym for idiot.  That's a good joking start, and because of that, it was written by Linus Thorwitz, and  he said he is an egoistical bastard, and he names all his projects after himself, and  that's why he named the project idiot.  And actually, this is, if you don't know it, it's the source versioning system for the  Linux kernel, and the history of that was Linus used a commercial system named Bitkeeper,  and everyone was mocking around, ah, ah, ah, it's not open source, and then he said, okay,  I cannot use it for free anymore, because Bitkeeper is not giving it me anymore for free, so I  will just stop writing code for the kernel.  I just write my own versioning system, and he named it Git.  Well, so because it's a synonym for idiot, I thought it fits me.  Because I usually forget stuff I write, so back in time, and I need something to keep  track of, and something to remind me, and with most of the bullet points here are commonly  known to every kind of versioning system, but some kind, some points are easier in Git,  or anyway, it's quite hard to change history in Git, because every commit is unique, that's  some major advantage of Git, and yeah, the main point for me is it does not forget anything,  so I do.  I can easily find everything I have done or others have done.  You can break stuff, but it's easy to not break it if you know some common concepts,  and everyone can do anything that is distributed, so clone is a full backup.  I have quite a good synonym for this, it's like having a linear game, you have to choose,  you have to solve, and at some kind, you just make safe games to solve it, and if you write  code, you have a multiplayer game, and in Git you have every safe game of every player,  and you can make a copy of every safe game from every player who ever played that game.  So this is quite a powerful image to consider, and this was quite the true.  Anyway, we won't go that deep into the system, but I will just give you three major ideas  where we can use this for project extensions, because that's just to get something to grasp.  So if you just Google, yeah, Git is better than X, because it has all this stuff, you  can easily just Google this by yourself, this was my first hit I got when I just Googled  why Git is better.  The slides will be online also, so.  And I pick one point, I pick any workflow just to give you one idea why this is better  than any other systems, or you can implement many workflows, you can implement a centralized  server workflow like in subversion, in subversion you just have one server, and you have many  developers who just have to synchronize with the server, and they have to fetch and pull  every time to the server.  And if the server breaks or something, it's where the versioning systems is not in sync  anymore and the project may delay, so the development may delay.  So this is one workflow you can use, and just to give you the idea, you can even define  the depth workflows where you have some master like dinosaurs who can only access to the  repository, and he just gives someone else the lieutenant person access to some more  developers, and here is a quality QA, and he does the next QA and then it will be in  the server branch.  So this is more or less one complex kind you can make, you can see that developer named  N, he seems to be better than developer 2 because he can check into Linus repository  directly and so on, you can define such a workflow with it as well.  So this is some theoretical stuff, now I go to the point, we use Git for our web-based  application QVTendo, and we have a project on GitHub, and we have release candidates  and beta and stable versions, and they've been managed by a timeline just on GitHub,  and we have the centralized server approach so everyone can commit, like five persons,  and if something goes boom, then usually some other developer just rewrote it or they communicate  via IRC or whatever.  So this is our case in our Git versioning system.  Sorry, I forgot to ask, so I have no clue, so on what kind of level are you into Git,  he's always nodding, so he seems to be, he agrees with me, that's fine, so is anyone  using Git right now?  Okay, and that's got two.  Okay, and you use it for your own project or for contribute to some open source projects  or what do you do?  Or it's also on GitHub?  Okay.  Okay.  The project on GitHub.  Okay, we can give some advice on that point, I postpone the answer.  And I'll just give you the information, before we use Git, we also use subversion, and this  was fine for me because subversion with this approach is okay, and if it's just somewhere  on a server in a company, that's fine, but Git gives me far more options, more power  in my feeling, and you can do some things with Git, you cannot do with subversion.  I will show some, I will make some stuff with rebasing, I'm quite sure you cannot do this  with subversion, so not so comfortably.  Okay, now for some basic stuff.  So I will, yeah, we go into the practical approach, we will just clone our project,  I prepared some stuff live, let's see if this works.  And then we go on.  Oh, sorry, no one can see this.  Okay, so now I just do a simple Git clone without write access, so this is...  Okay, this is a Perl project, so we have some Perl files and so on and so forth, and I now  have all the commits and everything which is in the major release line, which is posted  on GitHub, and which is actually the full working developer release.  So the next thing I, I will see.  So what do I do next?  I check Git log, like in subversion, you can see the last commit here, and what happens.  So if you use Git tag, you can see what kind of major releases are there.  So this is...  And where is Git?  So this is the current branch, you can see on what branch you are, this is actually the  current master, so we haven't created the local branch yet.  Okay, everyone follows so far, it's quite basic stuff, okay.  So what's the purpose right now?  If I have a client and I want to do a new project, it's best to start not with a developer  branch.  So, but we do not, actually we just install using everything with Git, so we just check  out the latest stable release, and I just do a branch then.  Okay.  So, let's see.  Okay.  So now I checked out the release 3.0, we are in a somewhat detached state, so we are not  on the current branch.  No, it's okay for you.  Okay, thank you.  So we are, okay, I checked out this release, so we are in detached head, we can check with  the branch.  So we are detached from release 3.3, so here we are, and then we just create a new branch  with this.  Can we call it new?  So now we have to create a local branch named toFroscon.  What I want is that the rest theory is in that branch.  So we-  We have to give branch.  Yes.  Yes.  That was my question.  Yeah.  So we have a new local branch.  Where there are a few visit.  No, no.  This is my-  Tell me a new master.  Yes.  With a new name.  Yes.  No, it's not-  I'll just wait one.  Give me 30 seconds.  I go back to the slides and then it'll be probably more clear.  Okay.  So we have a new branch.  The last commit is from 2012.  Actually, the last commit from the release 3.00.  And so what I did here, if we check on branch.  Then we have-  We are-  This indicates we are on this branch.  And we are in the version named text 3.00.  To make it more clear.  I can switch branches right now.  So okay.  This is now the branch master.  We are on that branch.  We check with get log.  We are in 2014.  This is the last commit right now.  So this is actually the full clone from the-  from GitHub.  Okay.  This is the commit message.  There was a typo in some translation.  Okay.  This is a commit hash.  This is unique.  And this is a commit messages and the commit date and so on.  Okay.  As you can see all the text.  Okay.  Okay.  Now we have created our own local branch.  We have a specific release.  So from that point we can start to do something individual.  From the project on a stable release.  And this is quite-  This is actually quite convenient.  Because I now can always cherry pick from the master if I want to.  And do whatever kind of modifications.  So usually-  So the point here is if I just check out the master.  Without creating a branch.  If I just modify some stuff like modifying templates or whatever kind I need for the project.  This will-  I cannot commit them because I don't want them in the major release.  I don't want customized templates in the major on GitHub.  And that's why I created a branch.  Everyone with me so far.  I have some slides as well too.  Okay.  I changed-  I already did this because this is a full installation of QVTendo.  So this is configured from the back server locally.  So we can see if we change something for the real process.  No.  It's just for convenience.  Just to see usually-  Anyway, the permissions are on VBV data.  So just for the web server and so on.  And you actually adjust-  Modified some stuff.  You need to modify some permissions.  And so that is working.  So I already did this because this has nothing to do with Git at all.  We did this.  We cloned.  Anyway, it's always the same.  You cloned completely from GitHub or whatever kind.  And then you see text.  You can see the slots where you are.  And then you check out specific versions.  If it's text, then you can see.  And then you check out a new branch.  And then you can do a branch.  And then you have-  Everything is prepared that you only work in your local branch without disturbing anyone else, even if you commit.  So that's the point here.  Okay, now there are three cases.  If I modify the source, what may happen?  If I upgrade to the next version, my extents may never conflict, always conflict, or may not conflict.  Anyone knows what I'm talking about here?  Anyone?  Other way around?  Any questions?  Okay, let's see.  What's the case?  Never conflict?  Do you surface with perfect measurements and get them onto a branch or something?  Ah, no.  No, no, no.  You modify something in your working directory and it will never conflict.  Yes, that's a good-  Everything that needs not to be maintained via versioning system, that's usually dead-possessing.  And in my case, in custom templates or themes.  If you have themes, you can add your own themes and so on.  You are not really, you won't check them into GitHub.  In a more common way, it's everything which is not under version control in your repo,  means that everything, every directory or every file which is not known to Git.  How can we make a file known to Git?  We use Git at.  Let's see.  If you don't know if you use, so you can check.  Okay, you can check if you have anything that you are not checked in with Git status minus  0 and if you just use Git status minus U, you can see, okay, I have a template directory  named Frostcon which is not committed.  So in this template, there are some latex print templates for invoices.  These are customized.  So this is a new directory and they are not in the main repository.  Let's check.  Let's see.  Okay, so this is actually the application.  This is a branch in that specific version.  It's a bit cumbersome right now.  Anyway, I just add some stuff.  Now we have a PDF.  This is created by a latex.  The latex templates are in the Frostcon template directory and they are out of the box.  So more or less from the GitHub.  What we see here is this is some identity stuff and here's a logo.  I would like to customize this for Frostcon right now.  Now we have something to commit.  What I do first is I add the current directory to my local branch.  Then I make this...  I just change some metadata right now.  Whatever this ifo.  Okay, that'll be enough right now.  Now we check.  Okay, here it is.  I like to visualize my commits right now.  I use VI from my favorite editor.  I just make an extension to use VimDiff so I can visualize what I did or what's the difference between the original file and the next one.  So it's easier for my mind.  I changed this command, this template command company to another company.  So that's fine for me so I'm quite sure I want to commit that.  So now I have made Git commit.  Just I typed in the entire template here and you can see what's new here.  This is everything is new because I just added this and there's one div, the identity from the template system.  So that's fine with me.  I just give it a commit message.  Okay, so we have made our first commit in our branch.  We can see this with Git log.  So this is the last commit on the release 3.0 and here's my first commit on that branch for this customer project.  And I changed the identity of the company.  And this is case one.  It may never conflict because we added a new sub directory for the template system.  Well, in this case for the print template system for the invoice and this will never conflict.  So this is now totally safe to be there.  It has a unique commit hash and that's it.  I skipped the point.  Okay, we can replace logo and whatever kind of stuff we want.  So the next case.  Okay, it may never conflict.  We had that case.  The next case is it will always conflict.  Can anyone think of a case what will always conflict?  Although it will always conflict if I upgrade to the next version.  It's a bit tricky.  Any idea?  I take bad ideas.  I take any hint.  Okay, this will always conflict.  Yes, sure.  Okay, if I delete files, it will always conflict.  No, but I just also some.  Now, I always conflict in this case.  There is, for example, there's a version just a hard coded information which will change every release.  Like change log, for example, in our case because in every release we make a new change log.  So we always conflict and there's a version file just like in Debian, ETC version.  We have that case also and this is a 3.0.0.  We just make a new version here and this will always conflict because it's, as a best practice,  always to set up a new version number if I take a new release and if I modify that file,  it will always conflict.  So this case really depends on the project or what your release management is doing.  And yeah, okay, and the next case is may conflict, what's that?  Yeah, exactly.  So all project source files I modify which are already there and I, yeah, in that case many files.  Okay.  I get to the point. Let's see.  Yes, we do that.  Okay, here is my version file.  You can see a 3.0.0.  my customer wants to have his own project version,  I just add minus cross-con.  OK, that's done.  You can see with Git status, I have  changed files here.  I commit that file, send it to Git.  Done.  If I check my log, I can see OK.  This was the next commit.  This commit will always conflict.  If I do a rebase or emerging against the next stable version,  and now for some modification in some source files.  Let's see.  I pick.  Where's my?  OK.  I pick a report on customers.  OK.  So here are default checkboxes right now.  I want to disable telephone and mail.  So anyway, my customer, my client gives me a call.  Oh, I hate this report, because everywhere I click on next,  I always see telephone and email.  And no one is filling that data in our case.  Please make a change to GitHub and remove those checked  box because we don't need them.  So this is we have a customer or a client who says, OK,  I don't need that.  And sometimes it's like, OK, everyone else in the world  should have my opinion on this kind of checkboxes  or on this kind of report.  And so the easy case is then, OK, I have a project branch  or a customer branch.  And then they can say, OK, for you in the project branch,  I disable the checkboxes.  That's fine.  I have for the commit.  That's OK.  And I have a branch.  And it's fine for me then.  So this is the cheapest solution to get the project going.  It's something to do with marketing and so on and so forth.  And we'll do that.  This is also a template file.  But this is maintained by JIT.  Sorry.  Too lazy to write.  OK, this is a HTML template system named Clue.  So we are here, in the report, in the report,  in the report, including the report here.  OK.  It should be the next year.  Oh, no, it's just falling that way.  OK, I have the HTML text here.  I just removed the checked.  Let's see if I edited the right file.  OK, so it's gone.  OK.  So I got my contact.  And let's go this.  Oh, yes, email is set.  OK, we check.  OK, I usually use GetDiff to see what I did.  OK.  OK, you can't really see.  But you can guess.  OK, that line is changed.  Let's contact phone.  And email.  If you scroll.  Now, this is the case in the original version here.  So checked, still active.  And in my modification, it's gone.  This is just for me.  So I always use GetDiff to be double safe.  I only edit the kind of stuff I want to edit and modify  and also do and check on the web applications  if I just call you right.  For the graphical output?  For the graphical output?  OK.  OK, now I have that also committed.  And, yeah, so all my commits are there.  I have three cases.  Never conflict, it may conflict, and it will  definitely conflict.  OK, what will happen next?  So the project is done.  So the minimum customization is over.  So what will probably the next thing to happen?  It's already checked in.  OK, let's say I'm on a server where the customer is  using this.  It's locally checked in.  So it's on my project server, and it's checked in on that.  And the customer is happy.  He doesn't see those checkbox there.  He has his own version number.  He can, where we alter some more identical stuff, like  changing logo and so on and so forth, that's done.  So what will happen next?  That's no.  No, I don't know.  I just keep those changes in my local branch.  So I don't want to, I can also push this branch to GitHub,  but it doesn't make sense.  Well, it doesn't make sense for the customer project.  If it's not a real benefit for the project in general, I  do not push this back to GitHub.  Yeah, OK.  Yeah, usually the server will be back there anyway.  So this is fine.  If I want to back up this, yeah, just on one note, on one  server, this will be, but this is another case.  So that's fine.  That's fine for the customer and fine for me.  If we'll be backed up in the normal backup procedure,  and that's fine.  Yes.  Well, he will work with the project, and after one or two  years, he will find out, OK, there is a new release.  And the new release has feature X and that cool feature.  And he really needs a new version.  And so what do we do now?  OK, I just visualized this.  This was the last commit on 3.0.0.  This is a 2012 commit from the release 3.0.  And the yellow commits are my branches, branch commits.  And two years later, I completely forget the old  extensions, and the customer wants to upgrade safely to  the current version.  Luckily, I have a project branch with Git.  And what I always do, and I find very convenient, and I  don't know if you do that, I rebase against master.  And this is like I check out the master, I make a pull from  the GitHub, and then I check out and go back to my local  branch, and then I rebase against master.  So did anyone do this before rebasing?  You did.  OK, you usually merge.  Or did anyone merge with Git?  Yeah, OK, merge is here.  OK, that's the main advantage of rebasing it.  This is visualized here, that if you merge, in subversion,  you merge at a specific point of time back in history.  So after the merge is done, you cannot see what was the  original intent of the commit.  Because if there is some more modification on the same file,  it will move back entirely.  It will, like on an ecological type of saying, it will go  deeper in the ground.  You have to dig harder and harder.  And if you rebase, the concept is different.  Because all the branch will be put on the current head you  are rebasing against.  There's a major advantage here.  So right now, if you merge this, let's say it was in 2012.  So I do make a merge against the current version.  So I have to integrate this commit in my branch against  the current version.  And then everything goes on top of that state.  Yes?  And if you rebase, it's the other way around.  So he skips all the branch, Git, and then just goes to the  2014 version, to the current version.  And then he revines.  He will remind my own branch against the current head.  So this means all this commits will be put on top at the  exactly point of time I'm right in.  This is a major advantage.  So the hash keys will be all the hash identifier is still  there.  And my original commits are also there.  So if it conflicts, it's usually easier to see where the  conflict is.  And it's a bit more convenient on a graphical point of view.  If you have some graphical stuff of your versioning  system, you just see, OK, this is all the customers.  It's extension.  They are replayed after the upgrade for the next version.  We see that in practice right now.  OK, anyone remembers the commands I had on the slide?  So what was the first thing to do?  No, there was one step before.  So we haven't touched this project for two years.  So first we check out our master.  And we pull against the current repo.  So now we get all the commits from two years against the  major release.  We have them in master with commits and unique hashes.  OK, that's the first step.  Now if the customer is now used to this, it won't work  anyway.  So we are now in some undefined state without the  customer extensions.  And we have the current version.  We can see we are on master.  We can easily check back to the branch here.  We are still in the 3.0 version.  Everything's fine.  But we just pulled the master to get all the commits and all  the actual changes from the last two years.  OK, next step.  Which one?  Yeah, OK, Frostconn.  Yes.  OK, and now?  Yeah, yes.  OK, what will probably happen?  We have three cases.  Yeah, at least one.  So we may get two.  And with the.  So.  Why not the repo release?  OK, you can do this also.  But this is a bit difficult.  If I do against the actual current release, I make a new  branch with the release name.  And then I can rebase against the actual release.  Yeah, you are definitely right.  No, you would just to cut it short, so you would do an  extra step there.  You would create a new branch with a current version, just  to be sure.  Or sometimes it's not necessary.  It depends on the state of the developer.  So the developer is fine.  So we checked that.  With a customer, we were based against master with the  current developer system.  OK.  And that's.  So we see we have a conflict.  And we'll use.  OK, so what's here?  What the?  The current hat.  So this is the developer version.  So the version file is at 3.10 unstable.  This is that box.  We can see our modification on the branch.  This is a Frostconn branch right here.  And we can see what was there before we did that  modification.  And on that box, my editor, we will decide what to do with  this conflict.  So any ideas what to do?  Yeah, great.  OK, this means there is a here's a, I don't know, this  is a conflict right now.  And that point, I need to look at.  OK, yes, your project is now in 3.1 customer.  We have a new release only made for you.  Great.  And that's fine.  Everyone with me so far?  OK, that's right now the developer.  That was on a change.  That was before the change.  And that's how I get there, integrate, and decide to  handle this conflict.  Quit on.  OK, now he said, I forgot.  I said, git rebase me, minus, minus, continue.  I guess it's wrong.  OK, and that's it.  Yeah, sometimes you have to do them.  Perhaps this is already, let's see what's the look.  That's OK.  In that case, we didn't need that.  Sometimes you have to do this.  I'm not quite sure when this is the case.  Maybe it's only because of one line, I don't know.  But right now, this is a latest developer commit.  And you can see it's not a merge.  He did that, our commits after the last pulled master  commit.  OK, we had no conflict here because it was conflict-free.  For a question change, it was a case where it had to be a  conflict, and the default report is still working.  And so there was no change in that version.  OK.  OK, just as a reminder, we checked off master, we pulled.  Actually, we have to always pull.  And here we can do another branch with a release tag  whatever, and then we check out our local branch, and then  we rebase against master or the current stable, whatever kind  of commit where we want to rebase it.  And if we, OK, this is not, if you want to use a visual  itch, you can use git k, if this is not known.  So this is the output from git k.  We can change this also.  You can see this is our, here's the latest commit.  We rebased.  And you can see here is the master.  We, the point of commit where we rebased again, and you can  see we have three commits which I did here, live here, added  to those branch.  OK, so we have that here.  Just to be complete, so my git config use, which was not  explained in this live demo.  This is the RLE-ST just to use git diff.  You can configure whatever editor you want to have.  And you need to have some names and emails just to do  commit with git anyway.  And best online tutorial work is played.  I found right now, in short of time, was that one.  He had this analogy with using safe games, and it's a  multiplayer game, and everyone plays around the world, and  they get all the safe games from everyone.  This was quite a nice analogy.  So if you want to dig deeper into that, use that.  And if you, whenever you do at least some tiny custom  modifications for a project, just take those half hour  extra time to make a branch, and to commit against this  branch, and best case with git.  And then you have for safe, perhaps a lot of brain cycles  here to use later if you cannot remember what I changed  for that customer or at that point of time.  OK, great.  So that's what made a major point.  Yeah, then thanks to you.  Thanks for your time.  And questions?  We'll see you tomorrow.
maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__0_1235.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__1236_4343.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__4344_7439.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__7440_7487.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__7488_8699.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__8700_10463.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__10464_15599.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__15600_16043.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__16044_16907.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__16908_18419.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__18420_19283.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__19284_24359.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__24360_26039.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__26040_26435.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__26436_27707.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__27708_27995.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__27996_29927.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__29928_30551.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__30552_33755.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__33756_34511.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__34512_36863.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__36864_37115.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__37116_38363.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__38364_38807.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__38808_39719.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__39720_41303.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__41304_41615.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__41616_41735.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__41736_41831.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__41832_43187.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__43188_43679.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__43680_46403.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__46404_47339.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__47340_47675.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__47676_49631.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__49632_50039.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__50040_51191.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__51192_53099.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__53100_55619.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__55620_58031.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__58032_58103.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__58104_58835.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__58836_65507.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__65508_68147.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__68148_68399.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__68400_68591.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__68592_70319.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__70320_70799.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__70800_70895.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__70896_73991.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__73992_79307.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__79308_79595.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__79596_79991.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__79992_80195.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__80196_81383.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__81384_81923.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__81924_82691.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__82692_83435.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__83436_83987.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__83988_86291.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__86292_86411.png maintaining_a_oss_project_with_git_-_kivitendo__FrOSCon14__86412_86529.png