C# Course - Git Recap And Introduction

[Music] [Applause] [Music] [Applause] [Music] and with that let's switch to english welcome to an afternoon for get git refresh or git introduction depending on your previous existing knowledge about git i have a little bit of material for you this material is my git fundamentals course i will give you the link to this github repository through the chat window now so you can follow this link that i sent you here it contains all the different material that i use throughout this course it also contains as you can see here a link to the online slides so if you click on that one that will bring you to the online slides and i will show you some of the things here using these slides what does what does the material consist of it consists of the slides on the one hand side and it consists of some hands-on labs hands-on labs are exercises that we can do they are scripted so you don't need to fill in the blanks they are just step one to that step two do that and i really sat down and thought about carefully about these exercises so they give you a more detailed possibility to play with git and to learn these fundamentals of kit one tip i recently created another training which is not so much about git but more about git hub and i will also share these slides with you it's this one here i created this for teachers it's about what you can do with github as a teacher and i refreshed these slides in the last few days so i updated the samples i added a lot of samples i added new new developments around github so if you are interested in github 2 then you can use this second link but this is not the core of today's workshop the core of today's workshop is this material with git fundamentals good so let's go let's dive right into it i assume that you already know a little bit about git let's make that interactive okay um who can help me what do you know about the basic principles of git the following exercise imagine that a first year a first grader of the hater leondine comes to you and says hey i heard about git i've no i've heard the term git but i've never turned about git what is this git all about what would be your answer this is not an exam situation i just want to find out what you already know so i don't bore you so please join in and let me know what you already know or expect from git let's quickly summarize thank you for your for your ideas and your participation but let's quickly summarize it you see it here on the slides very quickly what is git git is a content store you said it's a version control system yes that is correct it's a content store for mostly code but you can essentially can store anything there please please please do not store large binary blobs so if you have for instance some large images videos uh virtual hard disks or something like this don't put them into kit there is a separate project which is called git lfs it's exactly for that so if you need that take a look at this project it is not part of today's workshop version control yes but what's the specific thing about kit version control it works in a distributed way you said that but it also supports branches branches has been supported by many many other conversion control systems too but the beautiful thing in git is that branches are so lightweight so you can create dozens hundreds thousands of branches and that's absolutely no problem for kid you are not that old as i am and therefore you don't know the history you haven't felt the pain of branching and other version control systems before but believe me if you go back a decade or two and you would have to branch in a version control system oh that would have been a pain but now in git that's really really nice collaboration you said it so i will not repeat it then the next very important question is how do you interact with git do you interact with a gui or do you interact with a cli a command line interface and my answer to that is just choose choose whatever you like in some situations i use the cli in some situations i use a gui and sometimes i use the client which is integrated in my ide in my integrated development environment i mix and match however it's just necessary for me okay so choose whatever you want in this workshop however we will focus on the cli so we will do a lot in the console why it's easier for me to demonstrate it it's easy for you to follow along because you can simply copy code from my slides it is much harder with a gui because then i had to show you i don't know some screenshots and things like that much harder to share with the cli that's much easier however again although we use the cli here it's perfectly fine if you want to use a gui in your everyday work so which gui again whatever you like here are just three of them three of them which you might already know github desktop very simple very good integration with github git extension my favorite gui tool but it's just yeah my my flavor i like it most get kraken i know a lot of people who use get kraken source tree would also be a nice option that many people use and many many other ones okay if you once understood the principle of git it doesn't matter which ui you use they are all very similar okay we discover that so what is now now we have to talk about servers because when we do collaboration we need some kind of server it's not a peer to peer product we need a git server it's a a git server is a remote repository for distributed version control so you have a server you have your local hit repository and you can pull and push changes from the server or to the server many today's modern git server products they are not just version control but they are also project and task management you can review and discuss code changes for instance you can do continuous integration and delivery just a question does anybody know a continuous integration and delivery tool which is nicely integrated in git do you know any of the the products that you could use for your projects any idea come on don't be shy ever heard of jenkins or github actions or azure devops pipelines ever heard of things like that they are continuous integration systems which allow you to take your code from git check it out build it and deploy the results maybe into a cloud computing environment into a darker server or send it to your customer or whatever you want to do two things which rather recently came to get are code security scanning so there are many products out there which do code security scanning so they find vulnerabilities in your source code and last but not least package management nougat maven npm docker images they are also stored on git servers they are not checked in with kit but they are part of git servers here you see some examples i already mentioned some of them github gitlab azure devops code commit bitbucket and so on good and when we use the server product in in this workshop today we will use github just because it's free and it's there and it's fine but if you want to use a different one i'm fine with that too question no here it is it's not it's not it's not um it's no problem because i was just talking about the slides but thank you for pointing it out okay yeah so here you see it here in this course we are going to use github but yeah at the end of the day it's um it doesn't matter but i will use it up here so this was the first part of my slides and it was put theory and it was the only theory that i want to talk about now we will dive right into the basic commands don't worry i will not show you many many slides if i go down you see in my slides a lot of interesting things and you see a list of important commands and so on and so on but i don't want to bore you with my slides you can read the slides you don't need me to read the slides for you i want to do a live demo so we will dive right into it and check out all these commands you are invited to join along okay so please if you um participate in this training and you are not just listening uh create an empty directory i will do that here i will create on my machine an empty directory uh let's call it get students intro something like this but you can use any folder that you like and i will open it here yeah in the command line in my windows terminal and that's fine i will do it here by the way it doesn't matter if you work on linux it doesn't matter if you use mac or windows it works everywhere exactly the same nothing special here so please create an empty directory and open a command line inside of this empty directory okay good some basics how do you turn an empty directory you see this is completely empty how do you turn an empty directory into a git repository with kit in it if you just call git init here you see it you can try that you will get if you take a close look a hidden folder which is called dot git that's the git database leave your fingers from this folder it belongs to kit you don't copy files in there you don't manipulate anything there it belongs to kit as long as you don't touch this folder everything is fine if you mess around with this folder everything will break so this is property of git don't touch it now if you would like to move your folder this one into on maybe onto a different hard disk or whatever it's absolutely no problem but just make sure that you always copy the dot git folder with you as long as you move the dot kit folder with the rest of the content of the folder everything is fine if you drop this folder bad things will happen if you copy this folder dot git into another directory that already has a dot git folder bad things will happen so make sure that you have only a single dot git folder and it should be in the root of your repository and this is created with git init and now we have a local git repository we can start adding files and doing things like that i will in my case start visual studio code by just running code dot and that opens this folder directly here in visual studio code let's put this one on the right hand side let's put this one on the left the other way around left hand side and right hand side and let's work like this something like this by the way visual studio code has a terminal built in but i will use it like this because yeah it's it's a little bit larger and it's easier good now let's create a first file i will use just a little bit of javascript code because it's so easy uh to to follow along okay so create a file let's call it app.js and this is app.js let's say console.log hello world hello world good if i do that and i go to my command prompt here i can say git status git status is the second a very important command that you have to remember it gives you a nice overview about what's going on in your folder and currently as you can see i will make it a little bit something like this as you can see we have a so-called untracked file you see that one now i can create a second file let's do that that is the greeter.js and it will say console.log hello universe so now i have a second file and if we check that one now we have two untracked files now how can we put these two files into source control enter next statement kit add git add and now we can specify either a single file app.js or we can specify wildcards star.js or we can specify the folder name something like dot as for local folder current folder if i say git add boom and if i say kit status double boom we have two green files changes to be committed what does changes to be committed mean now comes a very important part of git that we absolutely have to talk about it's the most fundamental thing that you have to be aware of if you add files to a git repository meaning a folder then we call this folder the working tree or working directory if you add files to the repository using the git add statement that does not mean pay close attention here that does not mean that these files are now added to your git repository there is something in the middle which is called the staging area also known as index the staging area is like on christmas if you would like to to to to to make a present to somebody and to give away let's say three books then you have these three books laying around in your living room and then you put it on your uh on your your your gift paper and you take the first book and the second book and the third book and the staging area it's the packaging table it's the place where you can add one book after the other before you wrap it into the gift paper and put it under the christmas tree and that will be the third step so the staging area is there for you to prepare the commit the commit the last step is the step of putting everything together and placing it under the christmas tree placing it into the repository you absolutely have to remember that first step add files next step commit files okay this is a two-step process and this is why we are currently seeing changes to be committed that means these two files they are staged we can also unstage them see that one so we can take them out of our staging area but currently we are fine with that we would like to commit this code and obviously this is the git commit statement after the git commit you should enter a commit message which you can do by using the dash m command line parameter if you are on windows please use double quotes if you are on linux please use single quotes i'm here on windows therefore i'm using double quotes and i say add two awesome js apps and if you enter that we see two awesome javascript apps are now created see that one and they are added to the repository so if i now say get status everything is clean nothing to commit and this is what you want to see in your code directories nothing to commit working to your clean now we have it in the repository oops didn't want to do that sorry i wanted to do that so now we did both operations and now everything is under source control now comes the next step which is not that trivial we are now going to change something at the js we are going to create a for loop for let i equals 0 i is lower than 10 i plus plus and put something like this here and put the console log here so we now changed a little bit in your text files you can change whatever you want you can also change a single letter it's just about changing now how can we take the change that we have into source control first can remember status add commit status add commit kit status what's the status of my directory oh we have a modified file see that one and now comes the crazy stuff if i want to add my changes i also use git add so listen closely this is important if you remember that you will already make a huge step towards mastering git git add is not adding a new file to a repository git add means you add a creation a modification or a deletion to the repository so if you modify something you still use good ad if you delete something isn't that crazy you still use git add because you deleted something and you add the deletion so always use git add independent of whether you created something modified something or deleted something git adds dot bang and get status we have a modified file then we can again use git commit we did it before add loop for log statement something like this enter of course i forgot the m sorry good git status woohoo nothing to commit everything okay you now learn the next command git log git gitlock shows us the history here you see it shows us the history of our changes originally we started with that one this was our first check-in and up here we have our second check in add loop for log statement so log gives us a nice history every element every entry in our history has a commit hash you see that one this is the commit hash it's a long binary or hexadecimal number and this number is important because you will see it frequently in your github or gitlab or whatever additionally we have here something which is called the head the head is the current element on which you are currently sitting so your head is pointing to this commit where we said add loop for log statement it's easy to remember that this one is called a head because you could imagine the history of your code like a snake imagine that we have a snake here this should be a snake i'm not good in drawing and this snake has a history you see that one and this one is the head and if you go down here here down here you have the history of your code so your code is a kind of snake and head is pointing to the current head of the snake and yes you can walk down in history walk down the body of the snake and for instance um find a commit based on the head so what i can do next command that you learn git show i can ask kid to show me the details of a commit so i entered six six seven watch this one six six seven six six seven see that one so i'm adding this one and i can ask it oh that's what that was a little bit too short six six seven zero now it's fine and you see add and we edit console log that's correct but instead of using git show 667 we can also use the head to find this commit we can say git show head one and that gives us exactly the same because with this tilde what is the english name for this uh this this this letter i think it's called tilde right i think so you you know what i mean um this is just walking down one element of the head and this is important you frequently do that you have your snake this is the head and you just go back one element until the next element which is this comet here see so with the tilde one or two or three or four you can go back in history you very very frequently see this syntax and now you know what that means and whenever you see this syntax in the future you see this this uh digi this letter here and you remember my my drawn snake my my my snake here which represents the history and now you know what that means we have the head of the snake and here we have the snake and then we walk back one element i know it it's it's not technically perfect correct but i think it's a nice picture that can help you to remember the syntax so what have you learned so far get in it add commit status log show next one diff get diff get div currently empty but we can specify two commits which we would like to div so kit log gives us two commits and now we can say git diff and we say seven nine eight one and six six seven zero and if i enter that one it will tell me oh i specified it in the wrong order sorry we should specify the 6670 and 7981 in this direction and it tells me hey reiner you have deleted this line of code and you have added these three lines of code so this is the diff statement it allows us to see in the console the changes that were made when we compare two different commits we can use any commits it doesn't have to be two commits which directly follow each other it can be something in history and something now and of course we can use the head syntax again git diff and what do we do we first specify head 1 oops and head and that will give us exactly the same output because we are comparing the previous commit with a current commit this is the diff statement okay get diff awesome very good now you know the most important command lines and of course if you have a graphical client these basic operations are way simpler let me show you what i mean if i go here into greeter.js and i just copy this line here save it then guess what if you have something like visual studio code or github desktop or kit extensions you have an embedded git support see that one this is the get support of visual studio code you click on it and you immediately see exactly what we saw in the div statement essentially behind the scenes visual studio code is doing exactly what you just saw in the console so it executes a git diff statement and recognizes that a new line was added you see the plus here so a graphical client comes in really really handy but once we understand what it means to have changes why we have this plus here what it means staged changes why is it why is it called staged because we already know it's a staging area you can remember the three books christmas the packaging the gift wrap something like this that is exactly the case so we can add a message here duplicate log and this check here commit after the kit add we do the kit commit and then we have done exactly the same now can we also take a look at the history at our snake that we have seen before yes we can there is a really nice plugin which you can try in a visual studio code it's called git history i can quickly install it i thought i had installed it but for whatever reason it's not there if you have a git history you see it here then we can go to uh f1 history git view view view view view view history and if i do that one let me remove that one you see now you see the git log graphically in your visual studio code and you can do searching and you can look for other people once we push that to github or something like this and of course you see all the nice details you see the commit hashes by now you know where commit hash is you can branch you can tag and things like that don't worry we'll talk about that in a second and we can also click on something like this and then you see if i click on somewhere here if i click on that file it will give me the status of this file at this point in time so i clicked on that one and then i clicked on view greeter and you see only a single line was present because the second line was introduced later so git history is a nice plugin in visual studio code if you use a different graphical git tool that's fine too they all have the same features nice let me quickly take a look what i missed oh i didn't do that one where is it where is it where is it where is it here it is we had status add commit log diff show okay what we didn't do is check out we will do that in a second revert i'm not sure if i want to do that today because we have a limited amount of time tagging and stashing tagging is something that i would like to show you and stashing is also something which i would like to demonstrate in a second first ah let me take a sip of tea and give you the opportunity to interrupt me you are so silent i'm not sure if you are still there do you understand what i did could you follow along any questions let's talk about tagging and stashing that one is a nice one you can do a lot of interesting things with tagging and stashing start let's start with tagging first let's go back to our console and let's say get a log we are currently here with the duplicate log everything is fine imagine you that you have now invested a lot of time uh building your great app and you would like to publish this app to your customer or whatever and you would like to set a marker for that and for that you do tagging so you say git tag v1 for instance that will set a tag git tag v1 git log will now show you that this version is now version 1. now i can say get show v1 and guess what you see exactly the version that you gave to your customer understand what i mean that is tagging if i now change something for instance let add let's add a um hello world.js and here we say console.dear and put a javascript greeting and hello world something like this okay i'm fine with that if i take that one and say can remember git add git commit message add jason hello world you can do anything just change something and do a kit add and hit commit if i now see it log you see the tag is now here it remains here and now we have a new version and we could again say git tag the 1.1 hit log and you see here now we have the tags these tags can also be published to the git server so they will become visible for instance on github so tagging is an important mechanism of marking certain important dates in your code base you could do that whenever you finish a sprint and this will be the version that you would like to present us as teachers then you could use tagging so that it is easier for us to find a certain point in time where your code base was stable and represented the the code that you presented to us so tags are a really good mechanism if you just take a tag it will show you all the different tags so you know which versions to exist good that was pretty simple that was not very difficult now we come to something completely different we are taught we will talk about um stashing we'll talk about how we can stash things okay let me quickly open on the side my my notes okay i just want to make sure that i don't forget to describe anything here what does stashing mean imagine the following situation you're here inside of your code and you're just working on this code for let i equals zero i smaller than phone rings your customer calls you and tells you hey reiner you have a bug in your version 1.1 you have a really critical bug here in app.js an exclamation mark is missing you have to fix this bug now we have a problem because we are in the middle of writing code we haven't finished this code but the bug is urgent we have to fix it immediately now today there is no point in waiting we have to do it now that's a problem we could now undo everything we have done so far you can do that by the way here with this small little thing discard change but we don't want to do that because we spent so much time writing this temporary code here it's just not done yet and this is the situation where you use stashing so you go into your repository and you say git stash push like in a stack with a comment let's say um in the for loop something like this it's dash and if you now say kit status guess what it's clean again your changes see the for loop are gone we are back to the last stable version that we had but our changes the for loop hasn't uh isn't gone it's stashed it's like taking it and putting it on the ship in the bookshelf right to your working place later on we can pop it from there so let's fix the bug for instance something like this anything let's check in this stuff bug fix plus check commit now everything is fine we are clean again but now i would like to go on and work on the things that i stashed so i go back and i say get stash pop and that will take the last stash that i pushed get stash pop and if i take a look now here see it four loop is here again but the bug fix here is not gone the bug fix is still here so stashing is a really great mechanism if you have to interrupt your work and you quickly need to do some debugging for instance for a colleague or right before when preparing for a presentation for us as teachers you want to interrupt what you're currently coding go back one step fix something debug something do something and later on you take out these things again okay it is possible to do that graphically too see that one so if you don't remember all this gui all these cli commands it's perfectly fine if you do it through a graphical client but i showed it to you through the command line because you'd simply have to understand what stashing means and then you can use any client understand what i mean i hope you got that so stashing means put in work which is working progress to the side and pop it pull it later on out of the stash nice good very good so absolutely absolutely we will do branches in a second yep absolutely absolutely you can also do it in a branch in fact you should put it on a branch in real life but sometimes people are lazy and they do don't do branches and then stashing is another mechanism which you can use you're absolutely right thank you for pointing that out so you see the commands status add commit log diff check out you will hear that when we do branching show revert not important now tag and stash good if you want to learn more about these commands just click on them and they will bring you directly into the documentation and you can read all the different switches what you can do but in reality i fully understand that you will rarely type in these commands but in many situations you will just use a graphical client for that nice that is good i would like to leave the basics here basic commands and switch to collaboration and part of collaboration will be branching but i think we now worked for approximately an hour approximately i think we have 50 minutes or so so i think it's time for a short break get a coffee get something to drink get a snack whatever clear your mind open the windows and in let's say i don't know 10 minutes 14 45 let's meet at 45 again at 40 at 2 45 pm we will meet again in this meeting and then we will dive into collaboration so we will see what remotes are we will talk about branches we will talk about merges we will maybe talk a little bit about re-basing because you will hear that term very frequently and that will be the second hour of our recap in git okay so enjoy the break 10 minutes 2 45 sharp you will be back and we will continue see you in a few minutes so let's continue collaboration with git we have two topics that we have to talk about here the first topic is remotes and the second topic is branching and merging let's start with the first one let's start with remotes what are remotes and how do you work with them i will not go into all the details what you can do with remotes i will just show you the very basic principles and that which should help you in the future to more um uh more st to to navigate more stable in your code base and your different github repositories for instance if you would like to follow along i ask you to go into github and open any kind of github repository of your on your of your own or take one of mine i will put the url of this course's github repository again in the checked window so if you want to go to it then please do so and here you see with this green button here you can open a window where you can get a clone address you see this clone address you can choose whether you would like to use the https or ssh protocol and rather new or rather modern also the github cli yes you are you you read you're right there is not only a kit cli but there is also a github cli we will not talk about it today it's just a convenient way of automating things with github in our case i'm just copying this url here and i go to my command prompt so let's go down here and i think i already have this skid fundamentals let's see okay no i don't have it here no okay so we can do a git clone that's the next command that i would like to talk about go into any kind of folder and use the git clone command here with git clone you can specify the url if you press enter it will download all the code from this repository and put it into a folder which has by default the same name as your project name can you rename this folder definitely take a look in my slides i have the necessary command line option there and now comes the important part see that one after cloning i get the entire git directory by default that means you get the complete history of this product on your machine it doesn't absolutely need to be like that there are a lot of command line options for the git clone command you can for instance say i only want the current version no history and so on and so on please read the documentation if you need these special cases by default everything is in this git directory and now comes the collaboration part the the kit repository that you now have locally has a connection a kind of yeah kind of cable back a connection back to its origin to github and this is called a remote please try the following git remote if you say git remote let me open my notes here to the side give me a second yeah if you just say git remote you will see a list of all remotes and here you see origin this is the link back to github for my local repository you can also say git remote i think it's called show url something like this no get url get url if you say git remote get url origin then you will see the url where this remote where this remote lives so here we see that our current repository has been cloned from this very project and this is called a remote can you have multiple remotes yes you can it is possible to have a local directory which is linked to multiple remote locations to multiple repositories in the cloud to github to azure devops to gitlab whatever you can use that feature for instance to synchronize different skid remotes to get it from there and push it there things like that you can take your code and push it to two different locations and many other things if you think of forking if you have heard about forking again you can also work with remotes and forks and so on we don't have the time today to go all into into all the details and to be honest on a day-to-day basis you don't need to know all the details about what you can do with remotes if you are not a professional git administrator you probably are going to use google to find out the correct commands if you have to do something special however it's important to understand that remotes exist for git repositories and these remotes point to github gitlab azure devops or whatever git server that you use so if you for instance have an existing directory and you would like to join or or push your changes from an existing directory onto a new github project what would you do you would go into that directory you would call git init to create locally a new repository then you would manually add the remote git remote add and then you can push your changes to the new project so with git remote add you see it here you can add such remotes if you would like to transfer your code from one repository server to another repository server then you can clone the repository you can if you want to remove one repository add a different repository and push your changes in general in most cases you just do a remote you just do a clone and kit manages the remotes for you nice now we learned clone we learned remote and the next thing that we have to learn is pull if something has changed in your remote somebody a team member has pushed some code some new code into github for instance and you would like to have this code then you say git pull if you do that it will check whether anything new is present on the remote and it will pull down the changes into your folder it's in in details it's a two-step project process sorry it does a git fetch git fetch is just taking a look at what's new and then the pull statement pulls the newsing things down in most cases you don't care about fetch and pull and the differences in most cases you just pull and pull does the fetch automatically i just wanted you to heard to hear one time that there is difference between fetching and pulling fetching is just taking a look what's new but not fetch but not getting it pull means taking a look what's new and pull everything down okay these are the two things here fetch and pull now the third the next command that we need to discuss is the kit push command you already know that get push means take the changes and push them to the remote okay that's a push command very simple so don't forget you have clone manage remotes pull and push that was pretty fast because i think you will probably know that and by the way if you are using a graphical git client all these things are available here pull push clone all these things so you don't need to remember these things by heart absolutely thank you thank you for pointing that out and we will we should definitely demonstrate that that's a very good thing let me quickly demonstrate what that means um i will i will you can follow along if you want but you don't absolutely need to because i think you will probably understand what i do here and if you just take a look it's probably fine because it's more about the concept and less about the exercise the next thing that i would like to show you that we would like to show you let's quickly create a new repository that's pull problem demo something like this and let's add a readme file and the get ignore file for visual studio for instance and let's add a license for the mit license because we build an open source tool okay create the repository that should be pretty fast and here we are here we have some stuff okay now let's quickly clone this repository we have talked about how that works git clone bang pull problem demo here we are let's start visual studio code in this way here now let's add something in the license here copyright by rhinostrophic i have a second name which is manfred so i changed that one and in the readme file this is a little bit of lorem do i have the lorem ipsum plugin no lorem ipsum whatever is done here and i think we are good now my dear colleague is going into um into these files and the colleague is also changing things so a colleague of mine goes here and changes i don't know just this to the first name and through bar something like this and commits the changes good now here i am i have done changes to my license file and my readme file and my colleague just calls me and says hey i changed something on the server maybe a critical piece of code please get this piece of code because it fixes a really critical bug you should definitely do a git pull okay we will do that we will go in to get here here and we will do a git pull and we have a problem see please clean your repository working tree before checkout we cannot pull down the changes we cannot because we have local changes in our repository which we need to either try to push or undo because we cannot get the changes so what are the possibilities either we commit the changes and then try to push the changes and that will give us a conflict because we have two changes on the same file i don't want to get into the details of conflicts now we will take a look at them in a few minutes okay so what i do is i undo my changes to the license file let's see if the situation has gone better and you see now it's okay now i got the changes from the central repository because my changes on the files which are currently um which were changed which are pulled down currently are not conflicting with my local changes i still have my changes in readme that's file that's fine they are not critical so therefore everything is good now but as long as i had changes in those files which were changed on the server i cannot pull down the changes that's not possible because i think this is what you meant correct yes absolutely this is a really common problem i fully agree i often had have to deal with that so whenever you get this message now you understand oh my local changes conflict with the changes which i would pull down from the server i have to either as mentioned now stash my changes we discussed that create the branch we'll talk about branching in one minute undo my changes merge my changes or do something like this but i cannot just continue it didn't work it didn't pull down changes important thing good nice questions regarding that understand let me quickly delete this repository again because yeah this was just a quick demo and i don't want to pollute my github here goodbye done nice next one next one is branching and merging branching and merging is one of the most important things that you can do with git and this is where git really shines where it really is strong what does branching mean branching mean that you can work in different so-called lines or branches so in different versions of your code at the same time and you can easily jump around between different lines of development how it is called okay it's difficult to understand but it's way more easy to to see it in action and simply try it so i would say let's do a quick demo and let's quickly check how this works so i forgot the name of my here get student intro okay oh this one gets student intro so i'm back in my folder this is what i had let's do a quick to get status everything is fine everything is clean okay let's do a git log and you can remember the history that we did before with the two tags everything is fine now imagine in this little application here you would like to start a new sub project you would like like to start working on a certain feature working on that feature will take a while it will take you multiple days so you don't want to corrupt the main line of development main line of development is the line of development where all your colleagues will maybe test the software test your project or maybe you could build the version of the project and ship it to the customer you don't want to ship work in progress so we somehow need to isolate the work that we do and this is done using branches okay the correct statement to create the branch is the git branch statement git branch and then we give it a name for instance feature one you can call it whatever you like maybe we put the name the the short code of the name in front feature one good git status we are still on the master branch what has changed we created a branch but we didn't switch to that branch git switch rs feature one and if i now say kid status then i'm now on a different branch the main branch or master branch how it is called if you have an older version of kit well not not very older currently let's talk quickly about that there is currently a renaming going on uh with all this black life matters movement um the the community decided that master is no longer a good term for the main line of development because you know this master slave thing and so on it's not a very good term and therefore you sometimes today remaster and sometimes you remain for new repositories new settings new environments i recommend the word main the main branch but you often hear the word master and now you know the background of that okay so in the next few years we will probably have to live with both names but for new things called it main and you now know that master is the older word it's not a catastrophe if you use it but for new things we should avoid it okay but now we are no longer on the master branch we are in our rs feature branch and let me show you the magic of branching by having here on the left hand side my visual studio code i can for instance create a file here another greet.js with console.log console error let's say console error hello error something like this and guess what we are here see that one in this rs feature branch this is still work in progress we are not already done we are currently in the middle of development our app doesn't work it's it's somehow broken because yeah we we are currently developing it it will take another few days until we fix it but that is absolutely no problem we can easily go here add the code write the message write feature one which is work in progress for instance here we can commit this feature everything is okay because the master branch hasn't changed and look what's happening if i say git switch master please take a look keep your eyes on that file up here if i switch to master branch it disappears you see so we are now deleted says it here we are now on this on the main line of development this is the stable version of the code nothing has changed so i can take this one i can build it i can ship it to the customer i can test it i can do whatever i want and when i need to continue working on feature one i will again say git switch rs feature one do that and the file appears see it you can also use visual studio here click on that down here and you can easily click switch graphically between branches you see that one click and you switch between branches and everything else is done behind the scenes you don't need to understand the details if you have a graphical client like visual studio code can you have multiple branches branches of course you can let's quickly switch to the master branch and create a second branch let's check it get status we are again on the master branch and you know what it's not necessary to do this two-step process so it's not absolutely necessary to do oops sorry to do a git branch and then to the do the git switch statement here it's not necessary you can do it in a single statement you can say git switch dash c like create rs feature two and this creates the branch and switches to the branch so if i go here you see r is feature two let's add another file super duper world something like this we can add this one we can add super duper super strong greeter yes you can use emojis in git command commits yes you can do that and it really works so you see it in the history let's have a little bit of fun here i like using emojis in in git comments uh git comment commit messages so you see if i now switch to rs feature one i'll show it to you here see we have another greet if i switch to feature two another grid disappears and we have the super duper gritter here and that is the magic of branching and if i need the stable version again switch master then we are back on the stable version we have the original code everything is fine now how do you yeah absolutely absolutely too very good git checkout is just another name it's not correct the the original name was git checkout and with git checkout you can do all the things that you can do with git switch but they introduced the new git switch command because checkout sometimes was a little bit of misleading or hard to understand so with the new versions of git many people just use the git switch command but if you are used to kit check out you can do exactly the same and you can stay with check out and it works perfectly fine so to show it to you the same as git switch i can use the checkout rs feature one and it works exactly the same you see feature two exactly the same or master exactly the same the command switches are a little bit different and you can use switch or checkout both work thank you for pointing that out often if you take a look at stack overflow posts and so on you often hear get to check out and it's a good thing that you mentioned that git checkout exists because otherwise it would maybe um this maybe lead to confusion i i think i think so too yeah i think so too yeah i'm also in the process of changing my habits because i'm used to checkout and now i'm trying to use switch more and more because yeah as you said perfectly right it's the better wording here good nice so how do i get my changes from the feature branch to the master branch enter merge so what i do is i switch to the master branch to the target branch and then i can get merge my other branches rs feature one merge it bang and see another grid is here so we merge the feature branch into the master branch if we want we could even delete the feature branch we don't need it anymore but it it doesn't hurt it's just there we can also do the same with the feature two git merge rs feature two and the super duper creator is here now we have the another grid which was developed in feature 1 and the super duper greater which was developed in feature 2. now everything is stable and we are back in master so what is the what is the key thing that you should remember here branch early branch often that is what you should do when you work with git whenever you start working on something do it in a branch create a branch for that do your work in the branch and then when you're done get it back to master branch early branch often branches are very lightweight in git so it's absolutely no problem to have many branches they are super fast to create they are super fast to delete no problems here okay that's an important one you can have local branches a branch that you have never pushed will just be local but you can also go into a branch and call git push and then you can publish a branch on github for instance so you do not need to publish every branch you can have branches purely local and you can decide which branches to push now let me show you a little bit of background information this one is important for you to understand how this stuff works i would like to use a small tool which is called learn git branching i love it when i always when i um when i talk about git and merging and branching okay let me show you what we just did we did a git switch dash crs feature one take a look at what's happened here on the right hand side see that one by creating the branch nothing was copied the commit wasn't copied it's just a pointer in reality you created a new head you now have a snake with one body and two heads and they are at the same position it's just a pointer this is why git is so fast when you create new branches if you now commit something hit commit then only your current branch is advancing so the main branch is still on commit 1 and your rs feature 1 branch is on commit 2. if i repeat that it's always advancing the branch that i'm currently on if i switch back get switch to the main branch see the star here nothing has changed nothing is duplicated or things like that we are just back to this point in time and now we can for instance git merge rs feature one and guess what's happening nothing why it's just moving pointers it doesn't copy anything or duplicate anything it's just moving pointers because changing main to feature one is a so-called fast forward operation it just takes it zoup moves it to feature one and now we are on the same spot again things change very much when we really divert into multiple different branches for instance git switch dash c rs feature two then we commit something git commit okay we are now here and now we switch back git switch to the main branch and now we create the second branch git switch c rs bug fix one and now we commit something see now we really have two heads now we really have two branches one branch here on which we can work for the feature and one branch here where we can do the bug fix it's very similar what we had before um before when we when we did some stashing that was what professor schroder meant when she said instead of stashing you can work with a branch that is exactly what we have here if we work on the bug fix we can easily work on the bug fix it will not change the feature here we can easily switch to rs feature 2 and work on that one it will not disturb working on the bug fix here let's go back git switch to the bug fix now the bug fix let's say is completed we fixed the bug and we want to put it back into main so let's switch to main we are here in maine again and let's get merge the rs bug fix what's happening think about it for a second fast forward just moving pointers we just move a pointer down because this is in a sequential line you see it here so main is now rs bug fix nothing special has has been changed it is brutally fast it's really really good but now we would like to get in feature two git merge rs feature two and see what's happening now now we cannot just move pointers now a new commit is created this one is called a merge commit this is a separate entity and new commit where it is written down that the feature 2 branch was merged to the main branch this is no longer a fast forward operation you see for the first merge we had this fast forwarding but for the second merge we don't have a fast forward why because now we really divert it into two different development lines and therefore we need to somehow bring these things together and this is done with a merge commit you often see that merge commit do you understand that yeah okay good nice of course often bad things happen when you do merging the next demo is super important and it will be probably the most important demo in these entire in this entire afternoon i will show it here in visual studio code okay and of course my command line i i think i can run the terminal down here it's it's more convenient now okay so let's do the following let's start with git switch dash c and you branch this is my uh rs my irs idea one branch good i'm here in idea one and i'm now going to super duper gritter and i will add let's say here console log did i already say hello something like this okay let's commit this stuff git add git commit add another greeting good oh ah i'm in windows sorry double quotes good we committed it everything's fine the idea branch is done let's get back to master let's create another branch let's let's think let's say i created the idea one branch and somebody else git switch is now creating the xy idea 2 branch now i'm on the idea 2 branch and if i take a look at the super duper greeter there is no second console line but the idea too is very similar uh console error console warning um is this the right greeting something like this good let's save that one let's add this one let's commit this one uh question and we are good and you can probably guess what's happening now because i will now switch back to master merge the first one merge the x y idea 2 branch no problem absolutely no problem now we have the console here and now i'm trying the rs idea one bang and now i have a problem because two people changed the same line of code here if you take a close look kit inserted a bunch of lines the things here the the the um the colorized view here is done by visual studio code it's really just a bunch of text lines that were inserted by git so if i just kept the super duper greeter here uh i'm not i'm on windows if i type the super duper gritter here you see it's just text file it's just a text file and just text that was inserted the only thing that git told us is that we have a conflict it doesn't work automatic merge failed and now we have to help get about what it should do we could say accept current change then we would end up just with this line we could say accept incoming change then we would end up with just this line or we can for instance say accept both changes click and now we have both lines why not it's fine technically we have now solved the merge conflict you see so the first step has been done fix conflicts we have done that if we say kit status then we see we are currently on an unmerged path and we need to fix the conflicts we have done that if we decide the conflicts are so so substantial that we absolutely cannot get rid of them then we can abort the merge as you can see it here but we already fixed them so all we need to do is a git add dot and git commit m and let's say um merge merge changes something like this and now if i say kit status i am clean everything is fine everything is good why did i say that this demo was the most important demo of the whole afternoon because i can tell you merging isn't fun if you work in your team and you branch on day one and then you work for three weeks without ever merging your changes and then you think that git will magically merge all your changes together it will not work the first one who does the merge will have the good thing so this one this is the easy one but the second person doing the merge will have lots and lots and lots of conflicts so therefore branch early branch often but also merge often it's really important merge often so let me show you what i typically do when i work in a project imagine that this is my main branch okay i switch to my own branch kit switch rs this is my rs branch then i do some work during the course of the day i commit some things then i go home it's evening i'm tired i go home everything is checked in everything is in the repository everything is maybe on github or whatever you use next day i come into the office and the first thing that i do i am still on the rs branch it's i'm merging the main branch into rs because i want to make sure if during night or during the previous day or whatever somebody merged something back into maine i want to get it early imagine a colleague hit switch x y i did something wrong sorry git switch main now get switch i will i will use professor shoulder ps minus c minus c i forgot that one sorry now we are here now professor schroeder is also doing some comments here let me get rid of that another commit here and now she is done so what the sh what does she do git switch main git merge bs and good now i come back into office git switch rs i'm now here i'm not done with my work but professor schroeder gave something back on main so what i do is i say git merge main in the morning when i come in so i get professor schroeder's changes into my branch and i have them in my branch and now i can use them already and i can continue working that means if i merge later on my changes back to the main branch i am way nearer to the current status of the main branch so at one point in time i will do a git switch main and i will do a git merge rs and that will bring back my changes and in this case it even could do a fast forward because nobody else changed something since i have been merging the latest main changes into my commits so this is what i mean with branch early branch often but also merge often merge in order to not work for days or weeks on your branch and then have a horrible time doing resolving merge conflicts do you get the idea questions please give me feedback do you understand what i mean and do you understand the problem that i'm that i'm raising here that i'm stating here okay yeah you're welcome you're welcome good i like that you understand that in git if i go here you can see all the different branches here these are the branches that you pushed to github as i told you you don't need to publish every branch you can decide which branches should be pushed and you can't decide which branches shouldn't push shouldn't be pushed the same is true for tags you can create local tags and you can push tags you can also directly create tags or branches here so what i could do i could say this is my demo branch and if i would i will not do it now if i would click here then the branch is created on github and everybody can use it then it's no longer a local branch if i do a git pull i will get this branch from my github server and i can of course switch to this branch i will not do it now because this is a real repository and i don't want to pollute it so this is another option that you can do with these things here nice so yeah yeah christopher please the tag the tag is just um just a marker that as the name suggests tags a certain version in your git history with an easy to remember name so uh let me show you that one um if we take a look here in my little demo repository and if we take a look at the git history then you see it now looks pretty neat and if i now think back hmm which was the version the version one that i gave the customer was it this one or was it this one i simply cannot remember anymore luckily i have created a tag you see it so i so i see the tag here and i know ah this was the version you see yes exactly and you can't do you can do something else i don't want to show you that in the command line because typically you don't do that in a command line you can base a branch from this version imagine that the customer is now calling you and saying i have a bug he's really angry with you and you don't want to ship him the newest version because maybe there are additional bugs in the newest version which you haven't found yet but you simply want to change the single small items a single small piece of code that is the bug that the customer is currently complaining on so what i can do i can branch from here click on it i can branch from here see create branch give it a name this is my um urgent bug fix branch this one okay so i'm now in the i can now switch to my oops here urgent bug fix branch see that one now i'm on the urgent bug fix branch i'm here see that one i can change something here console log bug fix save this one i can check it in trip bug fix commit this will change my history you see i'm now here in urgent bugfix the future is invisible for me i based it on v 1.1 and now i can for instance create a new tag here and call it this is the fixed version so v1.1.1 okay and once i did that i can switch back to master exactly so refresh it whoops what did i do i pressed the wrong button sorry sorry sorry now refresh it uh here switch back to master and you see that one looks good so here we see the history and i can easily switch to my urchin bug fix to see what's going on so this is the current version that i uh that i want to ship to my customer do you now understand the principle of tags you're welcome so in real world you you typically whenever you ship something you typically create a tag in your history and you typically create a tag with the version number so you can always very easily go back in time to this version and branch from there in order to be able to uh to do some some basic bug fixing for instance and then of course you can merge the bug fix back into main or do a so called cherry picking i don't want to go into any details here because that would uh that is really a rabbit hole that we can dive in but um yeah you can bro you can get the fixed bug into the main but i will not go into details here okay good i would suggest that we now do a final break on this afternoon because we now uh i would like to spend the last i don't know 40 minutes or so on um a related but uh different topic we will now take a look at forking and pull requests and how forking and pull requests differ from branching and why forking and pull requests are important and when you should do them i would like to demonstrate that but before that let's make a short break so i would say it's now 37 let's say at 3 45 okay quarter before four we will continue okay short break get something to drink get a snack whatever and then we will dive into the last i would say 40 minutes or so where we talk about especially pull requests see you in a minute so let's get started again let's quickly go back to the slides here and let's go into the github flow it's called the github flow because it somehow is related to github but don't don't let it let the name fool you exactly the same principles apply if you use git lab or if you use any other kit-based system there is also a so-called kit flow which works a little bit different than the github flow but that's minor detail if you understand the basic principle everything will be fine so what is this github flow all about the core idea of the github flow let me open the uh the github guide here because it's a graphically a little bit more beautiful let's put it this way works like that you if you want to contribute code to a code base can be your own project can be an open source project whatever if you want to contribute code the first thing that you do is you create a branch once you created a branch you add some code to your own branch that is important if you think you are done then you create this one a so-called pull request so you are not pushing your changes onto the main branch that would be not polite you are way more polite you say hey dear team dear master of the main branch i have some suggestions which we could put into the main branch then a discussion will start your colleagues will comment on your branch they will tell you if they don't like the code or if they are if your code is awesome maybe you have to do some changes everything is happening on the branch and at one point in time you maybe take the code and you deploy it maybe in a test environment or whatever you do and if even your customer or your your team or you you your teacher like we for instance are happy with what you did then you merge the branch you are accepting the pull request this is the process that we have here and then the changes of your branch are on the main branch here let me show you how that works let's go into a new repo create a new repo here branching demo public let's create a readme file the git ignore whatever no not actionscript no i'm sorry that that's not possible this time let's take c and that's fine just to have two files that's all and we have um we have some code let's add a file here demo.c and void main whatever and i don't know uh printf uh something like hello world podesta i think something like this i i don't care it doesn't need to be a valid c code something okay we have some code here good now i would like to do an extension to this code base what do i do remember what we had before where was it um where was it where was it here the first step was create a branch okay let's do that we create a branch i will now do it online but of course you can do everything in visual studio code or in the command line but i will now do it online so i'm creating a branch let's say the feature one let's stick with that name create branch now i'm on the feature one branch now i can change the code we are now here in this phase so let's maybe go here edit it and put in hello another world something like this let's commit it it's still part of my feature one branch so if i go to the main branch the demo c still consists of a single line that's correct i will not actively merge my changes directly into the main branch something else is going to happen i'm going to create a pull request you see it here it's already suggested by github see it tells me feature one had recent pushes do you want to incorporate it into the main branch or if i go to feature one it will tell me hey this is one commit ahead so i created something else and i can immediately create the pull request for that what does pull request mean pull request means that i don't take my code and push it into the main branch but i will ask the rest of the team hey i would like something to be in the main branch would you please pull my changes in this is why it's called a pull request so i can describe what i did here i added some great features and i create the port request the main branch hasn't changed if we take a look at the main branch it still contains a single line you see that one but we have a pull request going on you see that one here so i can go here and i will see that reiner added some great features and if i'm now a different member of the team i can go to files changed and i can take a look at what reiner did you see it here i can comment on it i can click on that and i can say oh that looks great but can you please change whatever i can add a single comment or i can start to complete review if i create a review i can add multiple comments on different files different locations whatever i want okay if reiner comes in and sees okay i'm now the same writer uh and sees this comment and says yeah but um yeah uh you are right but i don't know what so what we can do is we can have a discussion here we can have discussion which can digitally work we can digitally work together on the same code base we can even if we go to the code switch to our feature branch and do some code changes i could for instance edit this file and maybe add some more exclamation mark and of course i can add i don't know an emoji and emoji makes everything better now if we go to the pull request again we will see that the code change is now part of the pull request see it so the branch stays connected with the pull request i can let's go back here we can have a discussion and we can still work on the pull request and at one point in time we are happy the whole team can say yes i am fine we approve what we did here that is great something like this we can submit the review everything is good see that one and then the team or one team member who has the necessary permissions can say yes that's fine let's merge it and if i merge this pull request the pull request will become see it here merged so it is disappearing and if we now take a look at the main branch the democ contains the content of the pull request so a pull request inside of the team is a way of having a place where to discuss code contributions if you would like to create something and then discuss it with your team members then a pull request is the right way of doing it and how do you do it create a branch write the code create the pull request discuss it test it and last but not least if everybody is fine with it merge it good now it could happen that you have team members who are not no not you don't have team members it could happen that you have people who are not team members but who still would like to contribute something to your code base how can you do that for that i will show you how to do forking why is that important let's take professor schroeder for instance professor schroeder would like to contribute something to this code base but she doesn't have right permissions maybe you as a team didn't give us as teachers write permissions we are allowed to see your code but we are not allowed to write into your code but still we would like to propose a code change we would like to propose a feature and for that we have another step in this series of steps of pull requests this is done with a fork step here what we can now try pick it if you want i can stop sharing and if you like you can share your code share your screen if you like no problem yes we can see it yes we can give me a second good now we see the screen here and ah i see you already navigated to my repository great would you please click on fork right up aside fork that creates a copy of the entire repository inside of one of professor schuler's repositories just take one of them you can't delete it afterwards it's not necessary it will now copy the repository into professor schroeder's github environment yeah i think that was just a click somewhere are we still in the right yes please go up up up and to code on the left hand side and you will now see on the left upper corner branching demo forked from our stropix branching demo and because it is now inside of professional schroeder's environment she is the administrator of this fork of this copy so professor schroeder could now change the demo.c file or i don't know add a new file do whatever you want just good uh-huh good this is perfect this is perfect and if you scroll down you can directly do a commit change that's fine if we would make it even more perfect then we would create as dedicated branch inside of the fork but let's keep things simple for now okay so now we can go back to the code please go to that main um exactly to the main page and now you see that this branch is one commit ahead of our stropic main so professional schroeder sees that she added some code which she didn't give back yet to me would you please create a pull request and if you take a look directly right beside the message this branch is one commit ahead of our stroping main to the right to see the pull request yes exactly i wanted to demonstrate this button if you click on that one everything is done automatically you just click on create pull request you can enter some comments if you want it's not necessary i understand it okay good and create pull request great please allow me to switch back to my screen this is my screen again and if i now refresh i have a pull request so this is now a possibility to professor schroeder to suggest a change even even though that she doesn't have any right access so what i can do now i can make a comment i can if i want just as i showed you before do a comment here on the code but for me that looks perfectly fine so i will immediately merge the change and say thank you here and now the pull request is merged professor schroeder got an email with a notification that everything was fine and if i took a look if i take a look at the demo dot c everything is okay so this is the additional step of forking and it's necessary whenever you want to contribute code to a repository where you are not a maintainer this is the additional step here so to bring everything together and discuss what that means for everyday work we need to talk a little bit about um i thought i have it here let me quickly show you ah it's not here sorry um i thought i had that in my slides i'm looking for a very specific eye yeah this one ah there is a good documentation from atlassian that showed different strategies for branching and let's let's close in the last few minutes with with some discussions here for your everyday project work if you are a very small team maybe if you are working alone it's a good idea to have a single master or main branch you see it here and then you have one develop branch where you can play around and every now and then you merge the develop branch into the main branch that works fine if you are a very small team or if you are working alone if it becomes a little bit more complicated then you can create a development branch and create the dedicated feature branch if you work simultaneously on different features and some of them might might be completed and some of them are still working process so then you create a master or main branch you create a develop branch from master or main you regularly give back the changes from the development branch to the master branch and you create various feature branches from the development branch the develo the feature branches flow back to the development branch the development branch maybe is published to a test environment and when everything is okay you publish it to the master branch this is a more elaborate project and i would say in your teams of three to three to five people this is a very good solution now release branches are branches where you have some kind of specific test environment some kind sometimes called acceptance tests or quality gateways where you would like to create a so-called release candy date with which you go to the customer and show the customer a final demo before putting them into release to be honest i don't think you need that in your projects in the hotel but now you have heard about it hotfix branches if you work in a really critical environment i showed you that before you use tags to tag certain versions and then if you need to quickly fix something you create a branch from the main branch and give back the bug fix into the main branch this would be a hotfix branch and you can even go i think that that was the the last one that they have here there are even more complex versions of doing that if you have many many people working on a lot of different features at the same time then you can even divert things down there and have dedicated version feature branches and developer branches and so on but to be honest my recommendation for your work would be either this one very simple very small teams or this one simple for small teams three to five people very good and then you can decide whether you want to directly merge into the main branch or whether you would like to do as i showed you before pull requests it depends that depends on your preferences and whether it makes sense for you or not so if i go back to my slides and if i go here we are done this is what i wanted to show you i offered you a quick introduction a whirlwind tour through git and this is what we did we took a look at the most basic things we took a look at branching merging and collaboration and at the end we also looked at pull requests i know that many of you if i take a look at the presence list not many students are are present here at the end it's the last week before the the holidays and there are different school activities going on but i promised you to record everything and i did record the entire course so those students who had to leave because of special school activities today you can take a look at this video i will put it on youtube and you can re-watch it and hopefully it will help you working with git do you want to add anything to our to our course here for students or do you think it was fine the question was um we should talk about whether every developer every team member has one branch and keep it up to date or whether a certain developer creates multiple branches for multiple features my answer would be if you manage to work on one feature complete this work and then start the next feature then it's perfectly fine to have a single branch in the simple projects that we do at the hotel landing however in practice if we work in a more complex environment you are sometimes as you definitely know you are sometimes forced to jump around between features you're working on feature one but then somebody comes to you and says hey we urgently need feature two so you need to stop the work on the feature one and switch to feature two maybe finish it or in the middle of feature two somebody comes and says we need feature three in practice you have some situations like that and then it's better to create feature branches but if you work on a steady pace you complete feature after feature maybe it's enough to have a developer branch but in reality feature branches are pretty cool and as you've seen branching is not difficult in git do you think that was a reasonable descriptions for this reasonable description for the students yep okay so i think we would have 10 minutes left but i think we are fine it's the second last day before holidays thank you for watching thank you if you watch the video via youtube have a nice holiday have a nice evening and maybe you have a few minutes time to meet in in discord and let's quickly discuss how we will continue after the holidays is that okay we will do that awesome good so thank you and goodbye and see you after the holidays bye

Channel: Rainer Stropek

Views: 1,920

Keywords: Git, GitHub

Id: M2tz-GASzR8

Length: 110min 44sec (6644 seconds)

Published: Thu Feb 04 2021