 All right, so I guess we'll start proper. So welcome, guys. Today, we'll be having an introduction to Git and GitHub. And this is part of a larger series of workshops called Hacker School. I'm Reynolds, a core team member of NUS Hackers. So as I mentioned previously, this is one of many workshops. The next workshop they will have is HTML CSS. That's going to happen next Saturday. So do look out for that. And of course, you can always follow our website for the latest updates. And of course, the links to the slides are available here. So this is the rough overview of today's introduction to Git and GitHub. So they're a good presentation, contains a lot of gifs and memes, so expect a fair amount of those. So we'll just start off with installing Git and creating a GitHub account. After which, we have a very crash course on what Git is followed by some basic Bash commands. So that's how you interact with your shell. And then we'll go in down and proper with actually using Git, followed by using GitHub, followed by some advanced workflows. So this is when we combine Git and GitHub together. And finally, we go into some quality of life hacks that could hopefully improve your Git workflow. Sorry? Yeah, and at any point in time, if you're running into any problems, I have a question to ask, do raise your hand and my friends will help you. And we also have regular bricks along the way. So we will use those time slots to make sure everyone's up to speed. Perfect. So if you haven't done so already, definitely install Git. So you can definitely find the links online and do create a GitHub account as well. Yep. So has anyone not created a GitHub account yet? All right, yeah, just do create one soon. All right, awesome. And so why don't you tell if you have installed Git to run Git in your terminal? And you're using Windows? Yeah, so if you're using Windows, you can probably click on the Git terminal app. So if you're not sure, raise your hand and it will help you. And once Git is actually installed, what you'll find is if you run this command, yeah, like this is all the output that you expect. The version number might differ, but this does us that hey, Git is installed. Yeah, so when you first install Git, you need to tell Git who you are, what your email is, so that it can sort of tag the changes that you make. So definitely run these commands in, passing your name, your address, and so on and so forth. This is just a one-time setup sort of thing. And to check that everything is set up as it should, use the final command git config.list and it'll show you everything that's specified. So yeah, so this is how my config will look like. It has my name, it has my email, and how credentials are set up. All right, yeah, and of course, you're gonna need a text editor to edit your files. No strong preference by any particular editor, but I would highly suggest either sublime text or Visual Code Studio, so both are free, so why not? All right, so now let's go in proper. So what's Git? So I'm not sure if you guys have seen this scenario before. You're writing a document for some report. You're happy with the current state, and hopefully true as, hey, I wanna make some changes, but at the same time, you don't wanna lose your previous state of document. So what happens in the end, you start repending all this numbers at the back, and as you make more and more changes, it gets a huge mess. So for documents, it's probably fine. In a sense that not much would really move, but imagine if you're working on an actual code base, a lot of things are moving around, and this sort of style of appending numbers at the end would be scale, right? So this is where version control comes to rescue. So you can get a version control as a software that allows you to track how your project changes over time, and you can give it a time traveler and back to the future. And apart from Git being the most popular version control software, there are other alternatives like Mercurial and Subversion, but chances are in 99% of companies who work in or whatever projects you may find, they probably use Git. So we're gonna cover a huge space by just using Git. Yep, so the first part would be looking into sort of like very basic batch commands. This is not really relevant to Git per se, but it's just useful to know, right? So if you're using a Mac or a Linux, you probably want to fire up your terminal. If you're using Windows, you would probably want to fire up the Git CLI tool. Yep. So those using Windows, like if you have any troubles firing up that CLI tool, do raise your hand. I'm just gonna pause a minute. Yeah, is it? Is it? Yeah. I think that's it for now. Yeah, that's it. We'll show more in a while. Do you have the previous one? Yeah. Yeah. Does anyone like, like does anyone not have like the terminal up and running? Oh, but you can see with this. Okay, fire up the terminal. Yeah, perfect. All right, cool. So like the first command we look into is the CD command, which is strong hand for changing of directory. So it's very much what it says on the tin. It does change us to the directory name if provided. So we can sort of see that in action in this particular GIF. Let's let it reset. Oh, it's too small, is it? Okay. I might just give a live example. So I'm currently in my home directory and if I were to do a CD desktop, we'll move to desktop. So you can sort of see like the state of the desktop in my window manager here. And you can see that there's another folder called my project. And if I wish to move into that particular folder, I'll just do CD my project. And most terminals come with sort of a tab auto-complete. So in this case, notice that the whole name is called my project. I can just type up to MYP. And it auto-computed for me. So like do free to play around and ensure that you sort of like get off a rough understanding of the CD command works. Yep. So the first part is like CD followed by the file name. That allows you to, sorry, the folder name, that allows you to jump to the folder. If I wish to jump out, I'll just do CD and two dots. So two dots is like sort of like the ghost on command allows you to go out of the current folder. Yeah. Like if you've lost this, open up the slides and take the GIF and hopefully that sort of like concretizes what we're talking about just now. Okay. So now that we have the CD command out of the way, we'll move on to LS, which basically lists your directory contents. So in this particular folder, I have two folders. So I have one folder called folder and two files. So notice when I press the LS command, the output sort of reflects what is sort of listed in my file explorer. Okay. So anyone who has lost at this point? I thought I had installed it, but then it went to this page. Just to make sure it's on the same page is anyone not able to run the LS command on your terminal? Yeah, let's just write it down there on that whiteboard. So to recap, CD allows you to move between directories. LS allows you to look into the directory and move on to actually creating the directories. So that's with the MKDAR command you can give us a short hand for make directory. And it basically creates a directory with a specified name. So you look at the GIF, I'm just calling make directory folder two. And once that command is run, we see that folder two is indeed created. Pretty straightforward. So now that we know how to create directories, the next one is how do we create files? Oops, sorry, yep. So before creating files, this other command which is called cat, it basically displays the contents of a file. So in this particular GIF, I have a file one dot text which contains the following text. And notice that the same text is spit out when I run the cat command. Then we have this, the next one is the RM command that removes a file. So don't know that that's permanent and can't be undone. So in this particular GIF, I remove file three and we notice that it's gone. And let's do know that it's like undoable. So like, yeah, look out. And I guess one thing that I sort of missed out was the creating of a file. That one is with the touch command. Yeah, so I guess one command I left out was the touch. Yeah, and that pretty much creates the file. Yes? I can't get out of this thing. Because I cannot best use anymore. Then when I call something else, so control C. Oh, control C. So like one quick tip, when you're halfway through typing a command and you want to bail, you should press the control C command. That allows you to sort of like exit whatever you're currently running. Like one, I can just do this. And let's say I give up halfway. I can just press control C and like it just resets it. All right, so let's quickly run through the last two but then I'll just give a very quick summary slide. So the next one is called the CP command, which is basically the copy command. What's this happening? Yeah, so let's go through two more commands and then we just have a very quick summary of all the commands they went through just now. So we have two more, which is the copy and the move. So this is like pretty much the same as control C, control V, so scenario. So CP copies the file and then MV moves the file. Right, and this is sort of like the TRDR of whatever we covered just now. So like the main reason for using these like bash commands is that like you interact with Git through the terminal. So like being able to do everything within the terminal is just gonna make things a lot more simpler. And like sort of notice like the analog between the commands here and like the stuff that you do in your file manager. All right, so at this point in time, anyone is still stuck or needs help. So at this point in time, is it safe to say that everyone's like comfortable if interacting with your terminal? Yeah, if that's the case, we can move on to the actual Git stuff too fast. Okay, sure. All right, so if everyone's comfortable if using the terminal, we'll move on to the actual Git stuff. So now we'll sort of run in, we'll sort of like sort of go into how we actually use Git. And a note here is that all the important Git technologies in McGintosh terms that commonly see if you sort of like look on StackWolf or Git and whatnot. So the first one, the first key concept that we're running through is repositories, it's often shortened as repo. And you can think of it as a collection of all the files and the history of these files. So a pretty nice mental model is to sort of map each repo to a project. So the next time I'm gonna create a new project that would correspond to a new repo. And it can live on a local machine like your current laptop. And it can also live on a remote server like GitHub. So we'll see how the remote server bit works in a short while. So the first one is to actually create your Git repository. So with that, we first create a folder, we go into the folder and then we run the Git init command. So I can just demo that here. All right. Can we in the last row see this? All good? All right, cool. So I'm creating my desktop file folder. I just create a new folder. I'll go into the folder. And I call it Git init. So assuming all as well, you would expect this output. So once again, if you restart this, raise your hand, it will help you. All right, so now that the Git repository is created, now it's time to create some files. So now let's just create a new file. You just run the touch followed by your name.txt. Yep, so once your file is created, if you open it up in the file manager, hopefully you can see the same file that was created as well. And then we move on to the next step, which is checking the current status of a repo. So now that we've added a new file, Git is aware of the change. And if you were to sort of call the Git status command, it would tell us that it has found this particular file and it's under the list called untracked files. Right, so we see a bunch of random terms fly out. We see things like branch, commit, untracked. All of this seems very foreign for now, but we will run through them in turn. All right, so now this is a good segue into sort of like how Git works under a nutshell. And for that, we introduce two main terms first. So the first one is what we call a commit, which is a record of files that you've changed. And then the next one is the staging area which sort of tracks changes that you wanna commit. So I guess a very good mental model for this is to think of Git as various boxes of commitments. So your current state of the world is described in a cardboard box. So that's like the lowest level commitment, right? So once you make changes, you're happy with the changes. You move on to the next level, which is to stage. So staging or the index can be thought as your wooden box. So these are things that, hey, I intend to commit these changes. And when you're really, really happy with these changes, the highest level commitment is to move them into a steel box. So once in the steel box, it's locked in history and for all purposes, it cannot be changed. So to run through that flow again, you first start in a cardboard box, lowest level. When you sort of stage the file, you move it to the wooden box. And then when you finally wanna commit that to history, you move that into the steel box. So notice there are like sort of two transitions here from the cardboard box to the wooden box. That one is done before we call the git add command. So next time I say edit to the wooden box, I mean git add. And then when I say move the box, sorry, move things from the wooden box to the steel box, that's why I call it the commit command. Like that's not make sense. So we look at two commands here, git add and git commit. So git add is from cardboard to wood and commit is from wooden to steel. So let's see how we use those two commands in action. So previously we really created the file, like which is your name.txt, right? So now let's move that file into our wooden box. So with that, we use the git add command. So the usual syntax is git add followed by the file name. As your projects get bigger and you have like more files in your repo, it's probably super tedious to run like multiple git commands for every single file. So a shortcut for that is to use git and dot. So they'll add everything in the repo. So let's do that. All right, so assuming everything is done correctly, once you run git add and then call git status again, what was previously read is now green. So this tells us that my file is now in the wooden box. Is everybody able to reach this particular screen? We have like one green line and like no red lines. Oh yes, so like all the changes you're making should be in the same folder in which you ran the git init command. Sorry if that wasn't clear. Yeah, so basically if you run git status and nothing appears, chances are you're adding the file in the wrong directory. So is anyone not at this state yet? It looks like everyone's good. So now let's actually move things into our steel safe box, which is to commit. So this will be run the git command, sorry the git commit command and the syntax is git commit dash m followed by some message describing the commit they have changed. So it's usually good practice to have the commit message to be as descriptive as possible. Because at the end of the day you're gonna run through the locks and you'll see what we wrote. So if it's like undescriptive like blah, blue, B, like that's not gonna be helpful when you look at it like five months down the road. So let's actually do that. So as you make everything went well, you sort of see this command and like it gives like a bunch of summary statistics like in this case one file changed, zero insertions, zero deletions make sense as empty file and then a bunch of random stuff. So anyone not at this state yet? So like if you made this file congrats you have done your first commit. And as a quick recap, this sort of describes the life cycle of a particular file. Hopefully you can see the energy between the boxes I brought up just now. When you first create a file, it's called untracked. So that's when it's our sort of like cardboard box. And when you make modifications you then stage the file. So staging is the process of putting it into the wooden box. And then the last step is to commit it which is moving into the SteelSafe box. So once you've sort of done a commit everything is back in sort of the state it previously was. All right, so once you make a bunch of commits it's sort of nice to know like what you have done so far and the commit sorry the command for that is the Git log. So 99% of the time you're just gonna run the Git log command and that will sort of give you like this long wall of text or like things that you've changed. So let's sort of demo that. Yep, so in this case it only shows one particular commit which makes sense when you have one. And I guess like for you to sort of leave this state you should press the Q button. Here I press Q or I can press control C to leave this particular like buffer so to speak. Yep, so you can imagine as you make more commits this particular window would show a lot more text but that will be for later. All right, awesome. So other possible options to Git logging are as follows. There's one that sort of shows a one line log for every commit. So that's pretty nifty if you have like a bunch of commits and you want to just have a high level look at what's happening. So let's demo that. Yeah, in this case that's one line. And we do have all that crazy information that we saw just now. Yep, and a bunch more that you can sort of check out your own free time. So like 99% of the time just use Git log and you can see what's happening. All right, so next bit. So now we sort of see like the sort of staging and the commit cycle. Now let's sort of take another step back and see what a typical Git project sort of looks like. So it's basically broken out into three portions. So the bulk is really sort of like the metal safe which is like where we store all the safe changes in and how it sort of looks like is a sort of like chain of commits because each commit is sort of like linked to the commit that came before it. So we can see sort of like this timeline-ish structure where the most latest commit is on the right and the newer ones, sorry, the older ones on the left. Yep, then you see these like orange boxes on top. These are what we call branches. Branches are sort of like pointers to certain points. It's like pointers to certain like parts of this long branch. And you can think of it as sort of like having different windows into different parts of the timeline if you will. And another key point of note here is that each commit is uniquely identified by what we call a hash. So what happens under the hood is that when you do a Git commit, Git does some crazy calculations, spits out a unique number and that number uniquely identifies your commit. So if I were to refer to this particular commit, I would refer to it by its hash which is like D8, 985. And two other items here are the stage or the index. So that's the wooden box I described just now and the working directory which is your cardboard box which I also mentioned just now. So I don't have any questions on this bit, like any part that doesn't make any sense. So maybe just one quick question. How many saves do you think we have in one repo? One, two, three, infinite. What do you guys think? So intuitively, it would make sense that there should only be one save for repo, right? Because suppose you have two saves, so which represents the exact state of the repo, right? So you think it's as safe as being like your source of truth, so there's only one save, right? Cool, yep. So now we're gonna bombard you with even more crazy terms. So the first one is hit. That's sort of like a reference to the last commit and that is pretty much where you are right now. So TIDR hit is where you are right now. Master is traditionally the main branch of your project. So as you start working on like bigger projects, Master always sort of reflects the current state of the project. A branch is a pointer to some commit. So you can imagine like sometimes you don't wanna look at Master, you look at someone else, somewhere else, and that's where branching comes in. Or suppose you wanna create work that would be independent of what's happening on Master, that's where branches will also come in. Then next bit is the cache, that's our wooden box, and finally the working directory, which is the state of the world that we're looking at. That's also like decouple box that I described previously. All right, so let's have a quick exercise to ensure that everyone's on the same page. So first one, add some lines to the text that you previously created and commit that change. So that's the first one, second one is now let's create a whole new file add some text and commit that change. So once you've done the first two points you now have three commits. First one being the one we created just now, the second one being item one and the last one being item two. And then for the last exercise, observe that when we do a git add, we're moving things from our cardboard box to the wooden box. Now the question now is how do I move it back from the wooden box to the cardboard box? Right, so basically I'm asking how do you do a reverse git add? And the hint to that is to sort of study the output of a git status when there's something in your wooden box. So maybe give you guys like 10 minutes to run this through. And like if it's still lost, that's like raise your hand and welcome to you. Yes. I'm just gonna say so add a few more lines to the, it's already, I mean I haven't created so I have created first or I can use it to my line to create, I don't know. So up to. So look at item one, right? Yeah, so I say this is the following creator, right? Maybe you open this up. Yeah, then like this type random things inside. So I say it's ready, right? So now go to your terminal. Where is this? Oh, it's in desktop. So first do desktop, cd.com. So. Okay, so you're in, oops, my bad. Maybe press Q. What's this? Oh, press. Q is a quit. Okay, cool. Yeah, quit, yeah. Okay, nice. So now that the file is created, what should we do next? So we have, yeah, so commit the change, right? I mean, but I have to like git status. Yeah, git status. To see the status of the git. Oh, so once I modify it, it's not in the steel box. I have to add it. Okay, so it's not in the wooden box. It's still in a copper box. I mean, but I have already added to the steel box before. Yeah, so once you, I change it to the content, I have to add it again to the procedure. So git, but how can I know my changes to this text? How can I know my changes to the, to this text? So git add. Oh, so you can see what you changed, is there? Yeah, I want to change it. Oh, so this is a bit ahead, but I guess once git did. Yeah, so it says that you added this line on David. Oh, I'm David. So this one, I git add, yeah. Yeah, because there's nothing inside of it. Okay, so you run git status. Git status, again. So you see the notes in your wooden box, and now we move it to the steel box. Only we get it to the steel box, we'll get to the final stage. Yeah. Have the name. Up to you, so maybe it's add more lines, for example. So if you look at git log, you'll see two commits. Git log, yeah. Actually rename it. Yeah, so you see this is the first one, and this is the one you just made. Oh, okay. So it's like commit, right? Like commit to what I have done. Yeah. So, okay. So this means I modify this text twice. Yeah. The first one, I did this, and I drew this. Okay. Sorry. I just want to ask, how can you, like, make my window to be like this? Because this is... Oh, it'll be a bit later. But you can just Google... That's always you after... Yeah. It'll be mentioned a little bit. Okay. Yeah, all the fancy things. Yeah, the fancy things are very cool, but it's very plain. No noise. Sorry, can I... I don't know. I mean, every time I want to create a new file, and I mean, I did it, I have to... Can I use the commit lines? Yeah. So touch, and then the file name. So it's already the same file name. Yeah. Do I need to... No name. Okay. Okay. So I... No, it's how to, like, to open it and write something. Do you have sublime? Sorry. Do you use sublime text? Sublime text. Oh, you don't have it? Okay, then let's run code. So you have VS code, right? Yeah, VS code. So it'll be code. And then the name of the file, new line. Oh, Vcode. Oh, Vcode. Okay, I'll use Vame. I don't know. Oh, Vame also can? Yeah. You familiar with it? No, no, no, no, no. Yeah. Hey. Oh, escape, escape. Escape. Sorry. Yeah. Then WQ. Oh, okay. So I think you should know the flow from here, right? Yeah. Data. Deny. Like, get add. The false name. Huh? Get add. Just wait. Okay, status. Okay. So... Is that case-sensitive? Oh, it's case-sensitive. Okay. I guess you commit already. So now your wooden box is empty. Get lock. Yep. Okay. Thank you, man. Err, anyone needs help? Be recreated and committed. All that. What are we supposed to do now? Just a bit. So like, add more lines to your name, commit the changes to the first item. Have you done that one? Yeah. To the text file that you created just now. So like, open up the file in your favorite editor. Add some lines. Okay. So like, open up the file in your favorite editor. Add some lines and commit that change. How do you open it? Like, on your desktop? On your desktop. So like, do you remember where you ran the git init command? Like, let me see where... Very far back. Okay, so it's... Sorry? Yeah. Yeah. So I think you make an directory called myproject. So open it up. So that's probably in your desktop, I imagine. Ah, there we go. Okay. Yeah, so you see that your file creator is there. Oh, I see. Sorry? Yeah, you didn't see the file. Then it's after committing it. So this is just steel box. So what's the question again? If you commit it, it goes to the steel box. Yeah. Then you edit the one which one I'm using. Okay, never mind. Maybe we just try the first item. So like, we just add a bunch of lines. So like, maybe just open any random file. And just like, add some lines to it. Yeah, sounds good. So maybe you want to save that. Cool. So now we... So like, by saving it, we now have stuff in our cardboard box, right? So if you run git status... Okay, so now we see that there are two things here, right? So apparently this is green, right? Which means that this is already in your wooden box. So I guess you did a git add. And now we have this one that's in your wooden box. So we... Oh sorry, this is in your cardboard box. So let's just move that one to the wooden box. So if you want to git status... Yeah, so now we can move everything to the steel box. Yeah, so that would be actually pretty much one and two in one go. Cool. Uh, anyone needs help? Yes. We just came, so we are completely lost. Oh, okay, no worries. Yeah, so just a quick run through. Have you installed git? Yeah, yeah. I see a VS code already, so that's nice. So the first part is just running through basic bash commands because you'll be interacting with git through like the terminal. So having this in your tool set will be pretty nifty as well. So maybe we... Okay, so I guess you're using Windows, right? So maybe you want to download this so you can load the GIFs. But... Sorry? What do you see on top of this? Okay, so are you familiar with bash commands? No. Okay, so in that case maybe you'll probably want to download the PowerPoint slide and then load the GIFs. So the GIFs will give you a demo of all the various commands. But we can do it later. I'll just give a TLDR summary. Can we just keep going forward? Yeah, so the TLDR, CD allows you to change between directories. LS allows you to list the directories. So the analog for this is CD is like clicking on the folder in your file manager. LS is like what you see on your right panel. And make directory is your new folder command. CAD allows you to print the contents of your file. RM is your delete. RM-R allows you to delete the folder. CP is your copy. MB is your move. So that's a high level description of the various commands. So then the next bit is we talked about what git is. And then here's some key concepts to take a note. First one is repository. Getting a repository as a mapping of a repo to a project. So each time you create a new project, you probably would create a new repo. So repos can live on your local machine, like your current laptop. And it can also exist on a remote server like GitHub. So that's the gist of it. The next bit is creating the actual git repository. So you create your folder, you go into the folder, and then you run git init. So you always run git init in the folder that your repository will be. Does that make sense? Okay, cool. So you do it through your terminal. Yeah, this one. Okay, so currently you are SPWD. You're here, right? So maybe you have a CD into your desktop. And then maybe you create a new folder called project. Mkdir and your project name. Like the folder, I don't know, project for instance. Perfect. So let's go into that project. So that's the, which command? No, we're going to go into it, right? So that'll be the CD change directory. So CD, then what comes after it? The name of the folder, I'll do this project. So let's do that. So you can press tap once you key in enough type P first. Yeah, then tap. So it's like all the complete. Yeah. So let's go in. Yep. So this is where we want our repository to live, right? So now we call git init. So telling git like, hey, I want this to be a git repository. I don't know, git init space. Yeah. Yep. So now this is a repository. Yeah. Then hopefully you can follow the rest of the slides. Yeah. So it creates a hidden folder. So like that's how git like, like sort of stores the data that it needs. Not really. Like it's a dot folder, which means that it's a hidden folder. I basically usually be touching it, but you can open it if you want to. But like you don't want to touch it unless you want to fuck it up. Yeah. You don't need to configure it anytime. Oh, no. It's in like this bit, right? Yeah. Oh, it's a one-off thing. Okay. So I see you added your email and whatnot, right? So it's a one-off thing. Okay. Yep. Yes. Oh, sorry. Yep. Yeah, pretty much. So that's the first two points, right? Yeah. Okay. Yeah, then maybe try to figure out the last one now. Yes. Just want to ask it. Yeah. After I commit, how can I see what is in this commit? Like one of the files that will change those. Yeah. You see, like after we commit, we still want to change it. Okay. So let's say like this second commit, you want to make more changes to the second commit, right? Yeah, but I accidentally committed. Oh, okay. So usually the hack is called git commit dash a. So git commit a man. So even I can Google it, git commit a man. So it allows you to modify the last commit that you've done. Yeah. So what happens for the, what happens to your file when you commit it? Is it stored in some other place? Yeah, so it's stored in, so if you open up your folder and find it. Okay. So you see these files, right? So if I were to do this, so the A flag means reviews everything, right? Oh, so you didn't want that. Yeah. So you see that there's this dot git that's hidden. So git tracks everything that needs in this particular folder. So this commit is stored in your hidden folder. Yeah, it's hidden somewhere. So it's all in here. I mean like as far as the end users are concerned, we don't need to care. And like in fact, you shouldn't touch their file, unless you know, like fuck everything up. So for like how do we reverse it to previous one? Fuck it up, right? Yeah. So like there are many ways. So one is, we'll talk about it later. So once you check out, let me see if you time travel or you git reset. This one is just for local, right? Yeah, just local. So currently I think it's local. In the later part, we'll sort of like teach how you would sync it with a remote version. Okay. Yes. I think it's there when I'm running it. I'm a little bit behind now. So I was running this one. Okay, you can try to copy the first one. Oh wait. Okay, so you need to run these two commands. Is it because it's not synced with the... No, no, no, no. So the thing is, again, you need to know who you are and what your email address is. So just put in the... So you just run this two with... Yeah, with whatever details you want to pass on. Similarly for my... I have to run these two commands as well. Git reset author. That's weird. Have you used git on this laptop before? I downloaded files from git before GitHub. But I haven't used git before. So I mean, it depends on... From here it says that your email is very set. So if you want you can just do git config list. Git config dash dash list. Dash dash list. Remove the space being dash dash. Yeah, right center. Yeah, so like, this makes sense to you. Where's your email? It's not there. I guess it's run the same two commands as it says. Yeah, so then you will know your username and your address. Has anyone not done the first two boiler points yet? So I guess like for complainers, I just like demoed the first two points. So the first one is add some lines to your previously created text file and commit that change. So let's just do that now. So I made some changes. And it tells me that there's nothing in the wooden box. Let me add that in. And let me just commit that change. All right, so that's the first one. And the second one is add a new file. Add some text commit that change. So that's also pretty straightforward. I'll just create a new file. Let's follow the same thing. Yeah, so now I've like sort of done the first two boiler points. First one being editing a file, saving that. Then the second one being creating a new file, adding new text and saving that. Right, so is anyone not at that particular stage? Or like needs help? So like ideally you should be really, really comfortable with like creating commits because like things can go a little bit faster after this one. So if any doubts, like now's the best time to ask. Anyone? Right, if not, then we'll move on to the third point, which is what is the reverse of a git ad? So like just a quick recap when we do a git ad, we're moving things from our cardboard box to the wooden box. So let's say like, hey, I don't want to do that. How do I move it back to the cardboard box? So to demonstrate, let's see how I do. So let's say I make some text edits. I add the file, I get at the file. So notice that it tells me that, hey, I'm modifying this file. It's in green. I don't want it to happen. And the hint is really here, right? Use git reset, hit file to onstage, right? So we just take the hint and it's just that, oh, onstage changes, onstage means that, hey, it's no longer in the wooden box. It's now in our cardboard box. So in fact, if we go back here, we see that the file, sorry, the file is still in its previous state. We didn't undo the changes that we made. Yep, and it does that, hey, text is in, which means that, oh, it's in our cardboard box. It's not in our wooden box. So with the git reset command, it actually moved it back to our cardboard box. So hopefully that solves the last point. So we'll go more in detail what git reset is, but this exercise helps you discover new git features as you start using more and more of git. So now that we've covered the basics of git, we're now moving on to git hub. So this is probably a term that you see floating around a lot in SOC, and so what is git hub? So git hub is basically the world's largest web-based git repository hosting service. It's owned by Microsoft, so it's huge. And you can think of it as a place where you can park your repositories online, even like show off your code or like collaborate with friends. And its main purpose is really just for code collaboration. Like people can see your code, you can make contributions to code, so on and so forth. And it also adds like additional functionality at the top of git. So things like a really nifty UI, like interacting through a terminal is really lame. It also comes with documentation. As your repository grows, you might add more documentation for people to see. That's one. It also contains things like issues. So you can think of issues as bug reports or feature requests. And then there's this pull request and review, which is sort of like the workflow in incorporating changes into the repo. And a lot more. So like two new, really nifty features that was added to git hub was jump to definition. Sometimes you look through code. You're confused as to what this function is. It can sort of help you jump to that definition and also can show you references of a particular function. So think of this as like an online text editor instead of writes if you will. All right, cool. So now I suppose the errand has really created your GitHub account. If not, really do so. It's very straightforward. It's free. And now let's actually create a new repository. So today is very simple. Once you are logged into your GitHub account, you'll see this green little button. Click on it. And then you fill up like some details like the repository name, a description if you want it, and then the privacy settings. So like there are two versions. So the first one is public, meaning that everyone can see it. And private, which means that only you can see it. So for now this is public, nothing sensitive in it. And once you're done, you would sort of like reach this page with like a lot of like crazy commands. So like go ahead and create your repo and like as usual raise your hand if you're stuck. So like if you're unable to reach like the last stage, which is the one with all the crazy code like let's raise our hand and I'll come to you. Give me just a quick demo. So I logged in, let's create a new repo. So I give it a name and let's create repository. All right, so is anyone not at this particular page? Anyone? All right, so like assuming everyone reaches page, we'll move on to the next step, which is syncing your local repository with the remote one. So this is what we call a push. So for now we'll just sort of follow the instructions in the page. So here you see that there are two possible instructions to follow. So the first one is creating a new repository on the command line. We've already seen that, right? So hopefully all these commands sort of make sense. So we have to get in it. So that's where you initialize the project. Here they're adding, sorry, they created a file called readme.md in the previous step. Now we're adding it. So that's the whole moving into the wooden box thing that we've been hearing a lot. Then followed by a comet, which is the whole steel box thing. And then finally a remote add origin and a git push. So here it's also the same thing, remote add and a git push. So how about we just run both of those in our terminal. So we just copy pasta this and run. And then we run this one too. So this one takes a while depending on your internet speed. And once it's done, you'll see this branch master set up to track. Remote branch master from origin. So a lot of crazy terms flying around that's dissected. So branch master is where we sort of like the branch they're currently on. Master is always the default one. And then we see this track remote origin branch master. And then from origin. So let's look at origin. So if you look at the preceding command, we did git at origin and then followed by this long, crazy URL. So you think of origin as like an alias to the long, crazy URL that we sort of keyed in just now. So TRDR, origin is the URL where your repo exists. And then remote branch master. You can think of it as like the remote branch. So you have your local branch and then your remote branch. So in this case, quiescent entity both are called master, but you can imagine a world where it might differ. But for now, we just go with the simple case where the local is called master and the remote one that's going to be its online version is also called master. And then the last step, we did a git push. So that's sort of like pushing our local master branch to the remote master branch, such that both are now in sync. So you can think of the push step as like your sync command, if you will. So assuming that it's done, we will now get, if you click refresh, you'll see that the files that you previously added are now reflected on your repo page. So if you complete this step, congrats. You have actually successfully pushed code on the GitHub. So is anyone like not at this particular page yet? Yes. Oh, can you go to your GitHub page? Oh, I think, okay. So the problem here is that you already added files here. So it's like you can think of as like this, your online version already has like moved forward and your local one has moved in another direction. So you can't really match the two anymore, right? So that's why it's true and error. So the two things are one is like either you delete and create a new one. Actually, I think it's the best way. I'll just delete this one. Go to settings. Oh, actually it gets, if you want to, can you see the... Yeah, it's like your remote is now like in a different state. So it's like it's diverged. It gives like diverging timelines. So I guess one thing to do is you create a whole new project and you re-run the same thing. So I guess the first thing is you need to delete this remote. So, okay, let's Google Git, remove remote. Yeah, remote. Yeah, so let's see. Okay, so we will run Git remote RM origin. Because you're obviously going to undo that. RM. Okay, so now let's go back to GitHub. This one. So maybe we just create a new project. I just ignore this for now. Yeah, new repository that works too. Just create it. Yeah, just create. Yeah, then re-run the same thing. It should work this time. Okay, so like, did anyone initialize the repository with like this checked? Like, did anyone actually do this by accident? Okay, so things that you shouldn't. Because like, what happens here is that if you choose to initialize your repository with README, what it does is that Git would automatically create a new commit with the README file. And the problem with that right, now, you already had commits in your local repository. Now the remote also has commits. So you can think of it as like your timeline already diverging. So when you try to push your own commits up, Git doesn't know what to do and you'll receive this weird error. So like, if you have encountered a weird error, let us know and help you resolve that. Sorry? Yep, so like, usually the error will tell you to pull first. So in that case, it says that how about you add the remote changes first, and then you push everything up, such that like, you can resolve this weird divergence issue. Yeah, but TLDR is like, you would almost rarely initialize it with README. Yeah, because like, you just do everything locally first. But like, if you encountered this, README will help you. README, use the DR. No, like, I need someone else to do it. Oh, okay. Yeah, I just reported that the tree is still here. So what do we do with it? You can delete it. Yeah, let's... It won't, because it's online. Yeah. Okay, okay. We'll make a new report. Yeah, yeah. Okay, it's like, this tree does everything on the online. So does that actually change anything? Which one? Like, does it screw up anything? It only screws up if you key in the code. Key in the code? So what's the whole question again? I'm not sure what my question is. So you said that it will screw up if you take the box, right? So is it only if you take the box and you key in the code that it will show you just now that it will screw up? Yeah, because what happens is like, the online version has its own commit, and then like, your local version has its own set of commits, and like, they are divergent. So when you try to push yours up, it gets like, oh, she can do this, and chose an error. Oh, okay, okay, I get this. Yes. That's the question, right? Yeah. So when you do, when you do push, right? Yeah. Origin, right? What does the origin mean? So origin is the, it's like the alias to the URL of where the, like the GitHub report as the URL. So instead of typing the whole thing, there's a tag, which is origin. The GitHub report, that means my own, that means if I, if I go to the GitHub.com, it means it's GitHub.com, whatever, right? Yeah, so like, for example, that one, huh? So that's... So actually, if I don't type origin, what do I type? If I say I don't want to type origin, then that means I have to type the entire thing, isn't it? I think that will work, yeah. I must type the entire, that means... Like, hdps, github.com, then the whole thing, huh? That means he's, that means if I say I want to push, then I have to push to github, then I have to type origin, right? In the case you can add a different remote, so you could call it like, instead of origin, call it friend, and then like, you'll be git push friend. Okay, okay, so I must add a remote to that link itself, right? Yeah. Okay, then the last thing is, I think it will be me, right? So what's the, what's the example that you say to github? What do I do? Okay, so like, do you know why there's a problem now, right? Yeah, I know, I know. Okay, so now what we want is, in order for us to push, we need to resolve the conflict, right? Right. So it has us to git pull. So git pull means, okay, I'm gonna pull the updates that are made on the online version. No, just tell me what to do. Okay, so git pull, and then git commit, and then git push. So just pull first? Yeah. But then, because currently you, that means the repo is really there, right? Yeah. And then you have a local repo. So you're trying to, the initial step is that because that repo is there, you just sync directly to that, right? Yeah. But now it's that you must actually pull first to your local. Yeah. Then after you pull to your local, then you push upwards to everything, push into it, right? Yeah. Okay, thank you. Is anyone still stuck in this, like, weird state because of, like, this checkbox? It's mentioned change ban. So what is master exactly here? I mean, what's it exactly? Oh, master is like, so no, master basically means, like, the branch that you're currently on. So like, by default, your branch will be master. So we start using branching workflows. Yeah. It might change based on, like, what branch you're checking out. And that will show on the GitHub? So GitHub will track all your branches. And separate it accordingly. Yeah, separate accordingly. So, like, this one is just sort of, like, telling you where you currently are. It won't show up in the directory. What's your directory meaning? It won't show up now. Yeah, so if you open the directory, like, you wouldn't really know which branch you're on. But how Git knows, right? This is hidden file called .git. So .git tracks what you're doing. And, like, the main reason why, like, in this case it shows all this, right, because, like, this was, this is sort of, like, developed by Git, right? So, like, it actually reads the .git folder and you see all these, like, nice things. If you open the same thing in your, your Windows terminal, right, the command prompt, you will not have that. Yeah. Okay, so can I safely assume that everyone's on this state? Like, if you access your repo page, it has all the commits they have fed. All right, let's take it as a yes. Yeah, so you can sort of see, like, how this Git repository sort of is a carbon copy of what we've been working on so far. You see that there's only one branch, which is master, which makes sense, that's the default one. And you can also see other nice things, like your commits. Like in this case, I have three. So you'll sort of notice that the hashes here are pretty much the same as the one in my local. Yeah, so observe that the commits are pretty much the same, right? So in this one, we have 8C9C, 8C9C, 663, and 564, all of them match up. So hopefully you can see how this is like a common copy of the local repository that we have here. All right, so let's keep moving on. So now that, like, you have successfully sort of synced your code with the online repo, it's a good time to introduce two new concepts, which is like pushing and pulling. So notice, so we haven't done pull yet, we haven't done piracy, it was a push. So push is basically adding your local changes to the remote repository. So just now, how do we get our changes onto the getup repo? We did a get push, make sense? And then the sort of converse would be a get pull. So you can imagine a world where you have multiple computers, you made some changes on computer A, you pushed it, and then now you move on to computer B. So computer B is sort of like behind, sort of behind the time, and to make it sync, you'll then do a get pull. So in that case, you'll pull the changes from the remote repository into your local repository. So push and pull. So you can imagine if you're working on projects that have multiple collaborators, you'll be doing a lot of push and pulling. All right, so now let's move on to slightly more fancy stuff. So we first sort of look into branching and merging, followed by sort of like merge conflicts, and then we'll sort of end off with creating your first merged pull request. All right, so now we'll look into branches and what they are. So branches is really like the killer feature of Git. Various competitors of Git does support branches, but it's usually at a very high cost because of some of the internals and whatnot. But TLDR, branches allows you to diverge from the main line of development. So for example, let's say you're working on some website, you want to test out some new possible workflow. So instead of making your changes to master, which will sort of affect the state of the active project, what you do is you create a new branch, you make your changes, and those changes will be independent of the main line of development. And once you're happy with your work, you then merge it back in with the master. So that whole process that I described just now is what we call the branching workflow. When you branch off, work on your stuff, when you're happy with it, you then merge it back. So with that, there's a quick recap. Master is really the main branch of your project. So in an ideal world, you shouldn't be making commits or master by instead on your own branch, and then merge it when you're done. So I went ahead myself just now. When you're done with your work, you just merge it back to master. So I guess one interesting point here is that when you do a merge, you create a whole new commit, which is here. So you can imagine, for example, let's say your master has two commits, your feature branch has these three. When you merge together, there will be a whole new commit that's created. And we'll also demonstrate that a bit later. So now let's actually create a new branch. So the syntax for that is the git checkout dash b followed by the branch name. So what checkout is, we will sort of go into that a bit later. But for now, we just memorize that when you want to create a new branch, you just call git checkout dot b. And then once you're done, you can run the git branch command to see all of your branches. So I'll just quickly demonstrate that. Notice that it created a new branch and it checks it out. So I'm currently in my branch. I'm no longer in master. And if I do a git branch, so it shows two lines, first one being master and then the second one being my branch. So notice that there's a asterisk here indicating that hey, I'm in my branch. But if you're using the git console windows, it'll probably tell you that you're on my branch. And my terminal is also set up to reflect that as well. So I guess one another important thing to note is that because I did a branching from where it appears it was, the current state of the project is identical to where it was previously when I was still in master. Make sense? So now the next step is to develop our new branch. So at your own time, let's make a bunch of random commits. And then once you're happy with it, we will then push that branch onto our remote repository. So once you push this branch and you go into your git repository, you now see that there will be two branches, first one being master, which we pushed just now and the second one being the new branch that we just pushed. So let's do that. So in this case, I just make a bunch of extra lines. Let me just commit that. So if you wanted to actually see the git log, and you now see a bunch of really colorful text. So now observe that the hit now points to my branch as we sort of mentioned previously. Hit is sort of where you currently are right now. And because we made this commit on my branch and not on master, we observe that master is now here, which is like one commit behind us. And an added bonus here is that git also tells us where the origin master is currently pointing at. And you can sort of see how both are at the same place, which means that our local master and the GitHub's version of master are in sync. So is anyone like not at this particular state yet? So assuming that you are, go ahead and push this particular branch up to your git repository. So the way to do that is readjust this command, git push origin and the branch name. So let me just do that. All right, cool. So once that is done, I can go back to my main repo. So you see a couple of things. So the first time you sort of see this like weird yellow dialog box. And if I click on branch, I'll now see that there are two branches. So like if everything went well, like you sort of see this. If not, there's a reason I need to help you. So is anyone not at this state? If not, we can move on to the, like the whole merging process. Yes. I'm not very sure what to do. Git status? After I create the, right? Yeah. And then what actually happens here? Git add, yeah. So what am I actually doing? Like what, how do I, so called push changes? So that would be here, right? So you get push origin, my branch. So that's between saying, hey, GitHub, hey, get pushed my branch up until the online repository. And what the online repository is, it's origin. So like how do I, I'm supposed to do? What thing do you mean? Like, so I think you already done that, right? For them, they have like 5 stars. Oh, so I mean this is like random. It depends on what changes you made. So like, it would depend. So now I made like no changes. So you have, so notice that here you already checked out of my branch. So that's, so notice that master my branch. And then you made a commit here. And the commit looks like it went through. So because of that, my branch is now actually a master. Oh. Makes sense, right? Because like we, we branched out and then we made a commit. So masters here, my branch is here. And now I'm pushing this onto GitHub. So GitHub now snows. So GitHub now has like two branches, right? Master and your my branch. So if I make changes to my branch, I'm part of the master. No, it would be my branch. All right, cool. I'll just assume that everyone has like successfully pushed their branch onto GitHub. So now assuming that we're happy with the changes that are made, right? We'll now go ahead with the next step, which is to merge all these changes into master. So there's usually two ways of doing it. So one is either you do it locally, which we'll do a bit later. But for now we'll just demonstrate how you go about doing that online. So if you go into your GitHub repo page, you'll see this particular button called compare and pull request. So we'll just click on that. That sort of kicks off the whole merging process. So what happens here is, so this is like a GitHub specific thing. We then fill up this particular form. Like the title will be maybe a more text. And then here you just like describe your stuff. And from here you can sort of see a summary of the changes that you're proposing. So in this case, I see that I removed this line and I add a bunch of these other lines. So you can imagine as you do more fancier branches and whatnot, all the changes will be reflected at the bottom. And suppose that you're happy with this change, you then click the create pull request. So like why it's called a pull request, hopefully you can see why that's the case a bit later. But for now we'll just treat it as it is. So in this case, once you sort of created the pull request, you will reach this page. So once again, it gives a pretty good summary of the comments that you're proposing. So in this case, I only made one comment. So it makes sense that the log here only shows one. And we see that we can see what files that will change this particular tab. And assuming that I am happy with this, I'll then just click on the merge pull request. So maybe just a quick recap. So observe that here I'm adding a bunch of text here. So notice that this is called branching text. And then if I look at master, will I expect to see like that branching text to appear in master? No, right? Because we really branched out. So in fact that is definitely reflected here. So see, in this case it's different, right? This only contains the text that was previously set as it was in master. So let's see some magic happen. So in this case, suppose I'm happy with everything. I merge the pull request. In this case, it says that it's merged. So what's happening here is that I'm merging into master. This particular branch that I created just now called my branch. So once I have done this and I see this purple button, basically means that my branch has now been merged onto master. So now that that's done, do you think that master has changed? Do you think that the state of master has changed after you've done the merge? Makes sense, right? So if you go back to our repository. So this was on master. Okay, so you can definitely see it here, right? The URL says blob and then master. Then you also have a master branch. And if you refresh it, you see that the change was made. So once you finish with the steps, congrats you made your first branch merge. But online, which is even cooler. Okay, so now a quick question. So as far as GitHub's concerned, this is how our master looks like. But how would master look like on our local repo? Will we still get these texts? Would this appear in our master version? My branch, let me go back to master. Okay, back to master. Boom, the text disappeared. What happened? Like why is my master here different from the master on GitHub? Anyone knows why? Yup, because we are all sync, right? The remote repository is now ahead of the local one. So how do we sync things up? What command comes to mind? Any idea? So we have push and pull, right? So which one should it be? Any ideas? So push move things up, right? The opposite will be pull, right? Yup. So now if I want my master to be up to date, I will then do a git pull. So make sure you check out your master first and then do a git pull. And in this case, notice that hey, the new part has indeed changed. And if I go back to subline, I reload it and boom. We're now in this happy state where everything is in sync. So if we run the same commands in your laptop and if you're not in the state where your local master is in sync with your remote master, which I will help you out. Yo! Looks like it's working, but it says everything is up to date. And it doesn't actually merge. Yeah, so there are still two branches. So what? Already again? So you're trying out the merge conflict bit, right? Yeah, but merge what? I mean, there's no specification of what to and merge. I mean, merge file name, merge the branch or what? Everything is up to date. Git merge master... Oh, okay, so how the git merge command works is this is the branch that you're merging into. Into? Yeah, but in this case, what's happening here is you're trying to merge master into BBC, which would probably work, right? Because BBC was a branch of master. So as far as BBC is concerned, there's nothing new from master to merge into. So I guess what I probably want is to check out master and then merge BBC in. Why is that in both branches? But the one BBC is new and there's more of that. Yeah, so I can imagine you want master to now have the changes that were done in BBC, right? Yeah. So for you to do that, you need to check out master first and then git merge BBC. So switch branch to master and then... Okay, so the first thing I'm going to do is git check out master. Yep, and then git merge BBC. So what happens previously is you're trying to merge changes in master into BBC, which wouldn't really do anything because BBC is ahead of master, right? Okay. Yeah, so when you call your merge command, chances are you're going to be a master. Yeah, unless there are changes in master that you want on BBC. You're going to the wrong direction. Sorry? So it was basically just trying to go from the wrong direction. Wrong direction. From the one I had in master. I'm not so sure about the directions per se, but the whole basis of merging is like some branch that I'm working on has changes that I want in my current branch. So in our case, BBC has moved ahead of master. So let's say I want the changes on BBC on master, I'll then do a git merge BBC from master. So that's one case. So another possible case. So I'm jumping the master branch into BBC, but not vice versa. Like vice versa is basically the word that one has already had. Yep. So you can mention another word where like let's say I'm making changes on BBC, like my friend makes changes on master. So my master moves forward, and I want BBC to have these changes on master. So what I'll do is I'll do a git pool so my local master's up to date, and then to get these changes on my BBC branch from BBC, I'll then do git merge master. So now BBC moves ahead, and has the same changes that were on master. But master remains unchanged. As in like it's my friend's version, but this master doesn't have the BBC stuff. Makes sense? This is like what I did, but it didn't work because there was nobody else changing the code. Yeah. You see this case? But if for example, like in this case, I switch back to master, change the master, and then like do everything, but with master changes, it will push those changes in my BBC. But not vice versa. That'll be correct, but like I would refuse to push, because like push me something else and git. Much, very much. For example, I guess you know how, I don't know, like first half of file as a master, I added something as like in the second branch, like just edit, and then in master branch, which back is edit at the first half. When I merge it from master to my current branch, or we'll write that thing, or we'll write only what has changed. You'll only overwrite what has changed. So the second half, which is like in second different branch, it won't change. Yeah. So that's what I call like a merge free conflict. But you can imagine a world where like both branches touch the same line of code. Then git will be like, oh, I don't want to do. Then it will throw what's called a conflict. And then like we'll sort of cover that a bit more later. Oh. Is anyone still stuck? Like I assume that everyone has like managed to merge their branch online and has it synced in their local repository, right? All right, cool. Then I'll just move on. All right. So we've done this step. Yeah. So just now we sort of used this command called the git checkout. And what it does is, it basically sort of allows you to sort of switch between like different versions of a target entity. So in terms of entity, there are sort of like two kinds, right? So the first one is a branch, which was the one that we used just now when we sort of switched between master and my branch. So if I want to go to master branch, I'll just do git checkout master. If you want to go to my branch, you'll be git checkout master. So on top of just checking out branches, I can actually check out specific commits. And that's pretty useful if I want to do like so-called time travel. You can imagine a world where you're making some changes. You know, there's a bug appears. And then you want to sort of like go back in time and see like when did that bug actually appear, so to speak. So one way of doing that is to just call the git log. And then like so figure out which commit you want. So for example, in this case, I want to check out this particular commit. And I'll just do this git checkout. So in this case now it tells me that my hit is now in this particular commit. And if I open up sublime, you'll see that the state of the world is like where it was when I made that commit. So notice there's this warning called detached hit. So why that's the case is it's pretty much self-explanatory. It says that we can move around, make changes. But you have to be a bit careful because now we're moving back in time, right? If you make any changes, git doesn't really know how to check that. So it tells us that if you want to make any changes, be sure to create a new sort of like branch. So like that creates a pointer which will then point to the changes they made. So there's that. That's a pretty advanced use case. Let's not really go too much in detail for that. And there's also this particular fancy term which is git checkout branch slash commit and file name. So that allows you to restore the previous version of a file. And that's pretty nifty if you just wanted to pull an old version of a file. So an example would be like same thing, you're doing some bug fix and then you figure out maybe the source was... Sorry, maybe you fixed some bug and you figure out that the code was actually working maybe five comments ago. So let me just check out that particular version of that particular file. So to do that, let me just go back to master. So my new file is back where it probably was. So imagine just now I was checking out this particular comment, 8c9. Let's say I only want the new text file. I just want the older version of the new text file. So the command I'll use is just git checkout the commit name. And then the file name, which is this new file. So open up. So once I sort of like checked out a particular file, the file is sort of like... It will sort of be like the state of where that commit was and I'm still actually in master. So in this case I sort of like yanked out the previous version of the file, but I'm still in master. And because this is sort of like a change in some sense of the word, it's now in our cardboard box. Oh sorry, in this case it actually moves into a wooden box, sorry. But at least they were still in master. So this is like an example of how you might check out a previous version of the file. Just to sort of like concretize everything. In this case I have a file with three lines which corresponds to three particular commits. I check out a previous version. And then now when we load the file, I realize that I'm back in the older version of the file. So that's how you might go about checking out a previous version of the file. Alright, so the next bit is merge conflicts. So just now when we did the online merge conflict, it was very straightforward because we were only like appending files to the end, right? So in a more complicated project, people will be making changes to various parts of the project. Chances are you and your friend are going to touch the same line. So when you do the git merge, what happens is that git is going to scream at you, right? Because it doesn't know who's changed to take. So in that case, it will then fail and throw what's called a merge conflict. So this is sort of like a very simple example. You can imagine a project where we have a text with four lines of code. And then on this particular branch or like the master branch, the second line is changed. Sorry, this is the conflict-free version of my bed. So in the happy path, what happens is you can imagine in a world where you have a file with four lines. This particular branch changes line two. This particular branch changes line four. And when I merge the two together, git sort of knows how to add the two, right? Because both branches were touching different lines in the file and the merge process is very straightforward. So this is pretty much similar to what we did just now when we merged our files online. We added lines at the end of the file. So git sort of knew how to merge it. So this is like the happy path, which happens probably like 1% of the time. 99% of the time, what's going to happen is that you and your friend are going to be touching the same lines of the code. So in this particular example, this particular branch is touching the third line like so. So instead of the letter three, we get two plus one. And in this particular branch, it's changing it to one plus two. So when I do a git merge, it shouts at me saying that, I can't merge as a clash. And when I open the file, I get these crazy lines. So what happens here is that the area of conflict would be wrapped with these angle brackets. The top half would be hit, which is the current branch I'm at. And the lower half would be the branch that I'm trying to merge into. So maybe you can try to run this example through. So what I do is I create a new file, right? So this is the current file. So let me just do this. And then I'll just commit this. So this is pretty much this particular state. So now let me just branch out first. So my new branch, in this case, I would change this particular line. It makes sense. So everyone looks sort of lost. So the recap, what happens is that first at master, I create a new file called text.txt. I create four lines. So the first one being 1, 2, 3, and 4 in spelling form. So now what I'm trying to do here is I'm trying to simulate a merge conflict. So you can imagine a world where I'm going to create a branch, and then I modify the third line. So you can imagine this is me. I'm in branch A. I change line tree like so. Then at the same time, someone on master makes a change. Master's tree. Imagine some guy actually did this. It makes sense. So now master is like this. Brunch is like this. So one thing will happen if I were to do this. It would fail, right? Because both branches, master and A, have touched line tree. Git wouldn't know which one to use. So if I run this, you tell me there's an error, right? And if I open this up, I'll get all these crazy lines and whatnot. So if you're using a decent editor, maybe colorize it for you and come out with nifty UIs. But for now, it is what it is. And basically what I have to do is I just have to resolve anything that's in this chunk of text. Is everyone able to reach this particular state? If you're lost, there's a reason I need to help you. So create your branch A, make some changes, and at the same time, make some changes on your master. And then once you're done, try to merge branch A into master. And you should ideally reach this particular merge conflict page. If not, then reach ahead and we'll help you. So who has reached this particular page? You can see all these crazy angle brackets. Who has really reached this? No one? Hi. Um, so I was playing around trying to just do what you were doing. I was trying to do a text editor when you would update your version of your hand line. You would update the text editor. Oh, yeah. I thought that was cool and I was trying to do it too. Oh, are you using Vim or like? I was using Notepad, but I've also got the ones you recommended to download. Um, anyway. So now I changed to my... I went back. Easier if I show you. Um, I was like, all right, whatever. I'll get this commit ID. Um, check out that ID. It's my project. Um, I got it. I opened it. It was blank. Just like when I opened it. Um, then it's still there. I tried to restore it back to my current project. I didn't change anything. I just was trying to have a look and go back. But when I opened it again, it's still the same. It's still blank. So how do I go back? But I should have about three lines in it. But it don't. So... So where were the three lines added? The three lines were added... added one line in here. Or there. And then I added like another line there. Oh, okay. On the top one. So... So in this case like you checked out. So that's probably when the file was still empty, right? Yep. So in this case you want to undo the whole project file, right? Do I have to just manually go back to the top one? In this case, it's a good reset. So... Probably reset hard. So reset dash dash hard. So that's like, you know, basically wipe everything. Like all the changes they made. Up until the last comment. So now if you were to cat the file... Ah, okay. Yeah, this works too. Yeah, then... Yeah, okay. Yeah. And so that normally updates. I had that open, which I did. That would automatically track on my local system. I think it depends on the text editor. Most of them actually... where like if it changes outside and bring the text editor in focus, it'll probably give you a warning dialogue saying like, hey, the file changed, would you like to reload it? Yeah, most editors should do that. If not, then that's kind of dangerous. Okay, so then how... Any questions? I mean, yeah, I heard you were done. Sorry. Okay, now I'm good. I'll make another branch. I'll try and do this now. Awesome. Then I'll ask if I want to get stuck. So how do I understand what this means now? Alright, cool. So... Anything that's between the arrow brackets are like where it's sort of like screaming, right? There's no... Like how to apply the change. So whatever that's above this equal line is the state of the world which is like the branch you're currently on. Master. And then this is the incoming branch. So in a way, yeah. So you can imagine like, let's say we're here and we get merge A. So A is below the like whole line of equal signs would be from branch A. And then this is the current branch around. Most editors will call this the current change and this is the incoming change. So like your goal now is to sort of like resolve between these two angle brackets. So do I just like type it manually or just say which branch is more... Of course. So use like more... and see text editors like VS Code. Like there will be like soft buttons where you can choose like accept incoming change, accept current change. Oh, so like you can open it up and then it will probably show it for you. Yeah. So now you see a bunch of buttons, right? So accept current change, accept incoming change and accept both the current change, which is it. So this is like suppose like wherever it's on the top half and just click on current change. So we click on that one. Everything below here. Yeah. Oh, this one. These buttons. So you can try it. You can click on this one. The green one stays. And then if I control Z. Yeah, then I can choose the second half. So this will keep the second half. Then you can choose Z that back. Imagine we want both. So we click both. You will take both and then like you will just manually edit it yourself. Should I demo that? Do you have multiple branches? Do you have multiple equal signs or what? You can only merge one. So you only have two. It's like you can only like merge a branch into your current branch. Like you can't really like merge multiple at the same time. So there will always be only like maximum two. Yeah, but like suppose like let's say I have master, I have branch A, branch B, and branch C. So let's say I want to merge all of them into master. I'll do it one at a time. Like you can't like get merged all three at the same time. Like that construct doesn't exist. Two questions. Can you make a branch off a branch? Yes. Cool. And if you have like 100 lines of code and you've got some stuff around line 30. But then because you add more stuff for four line 30, it like pushes the text around even though it's the same text. Would that still become a conflict? So it depends on... So in an ideal world, no. So you can imagine like a world where you have like let's say four paragraphs. We have like a bunch of lines between. Imagine like in branch A, I add a new paragraph here. And in branch B, I add a new paragraph here. So in that case, because like there's no sort of like marking around in like both areas of changes. Git is usually supposed to resolve that. Okay, so even if like these two push down the path where that one would be. Yeah. It would recognize where it is. Pretty much. Okay. Yeah. So it's like it really depends on like how smart Git is. It depends on the underlying algorithm. But in most cases, it would probably figure out that it's fine or it's like it's safe to do so. Does it promote clean programming? Clean. In a way. I guess so. Like it does some sort of like greedy matching. So it tries to like match as many like unchanged codes as possible. Yeah. So I think that's like how it works under the hood. Fancy stuff. Is anyone still not at this particular state? So if you're using VS code in my like sort of see this a fancy text. Yep. So like if you're using VS code, you actually get like a pretty fancy color highlighting. So in this case, VS code is smart enough to realize that oh, there's a conflict in this file. And it actually like sort of like highlights the areas of conflict. And then you get a bunch of buttons. I got buttons. Yep. So you get a bunch of buttons which sort of like helps you decide how to resolve this conflict. So in this case, we have disappeared again. So in this case, I have accept current change, accept incoming, and accept both. So maybe let's break this down first. So what happens is anything that's between the angle brackets, the opening and the closing one is where the area of conflict is. And we sort of, so what Git does for us is that it sort of splits in half. What's on top is the hit or AK, the current change. So this is sort of like the state of the text on our current branch. And the bottom half is sort of the incoming change which is like the branch we're trying to merge into. So usually we are presented with like two options, accept current. So that would sort of accept what's on the top half of the line of equal signs or the divider. So if I click on this one, notice that it will keep one plus two and it would remove the two plus one. So two plus one is at the bottom. I want the top one. So if I click on this one, it keeps the top one. And the angle brackets are gone, meaning that the conflict is resolved. So suppose I don't want that one. I want the one at the bottom, which is the change that I'm trying to merge into. I'll click on incoming change. In this case, it will keep the second one and then I'll get two plus one. Suppose like I want a mix of both or like instead of one plus two, I want one plus one plus one. So in the case, I can just do accept both changes, which gives me both, and then I can sort of like manually change it myself. So like if you use a smart editor, it's always like fancy tools that will sort of like resolve things. And in this case, like let me just pick the current change. And then once I sort of resolved it, I'll just do get status. It tells me that... So again, it's like weird text because I get sort of knows that I'm in the state of a merge conflict and it is telling me to just... If I want to abort, I just do get merge abort. So in this case, I'll be back to master, no changes were made. But if I'm happy with the current state of the world, I'll just do a get add. So that's like the whole moving things into the wooden box analogy all over again. So suppose I want to do that, I'll do get add and then text of txt. And then once I'm done, I do a get commit. So in this case, it would then generate the merge commit. And once I'm happy with that, I'm done. So that's how you go about resolving conflicts. Anyone lost? Anyone not lost? All right. So the question is, can you do it via code? Yes, you can. So it will pretty much be what we saw here, right? So you just manually edit this. In fact, if you're using a decent text editor, you should come with all this nifty UI that helps you resolve these conflicts. But if you don't want to, you can just DIY it. Or basically, all these crazy angle brackets is just to tell you where the emerge conflicts are. And you just have to remove all of them to carry on. In fact, you can even keep it there. You can even just shove everything into the wooden box and commit it. All these disgusting-looking angle brackets would be in your code and you'll probably break things. So hopefully, you'll be able to replay this whole merge conflict process. If you have problems, let us reach there and we'll help you. I created the bunch already. So now I'm trying to move it back. But then, basically, when I try to commit it back, untrack files, get status. So it's untrack, right? Which means that all these things are in your cardboard box. You can't commit anything because your wooden box is empty. So we should move things to the wooden box. So I created the process. How do we... Any on which branch? Is it my branch or what? You currently have branch A. Yeah, that's good. They're all being in branch A. It's a separate tab. So get the any.new then. On... What's that on my branch? Is that a folder? My branch is the previous exercise. I'm not sure. I think this is probably a folder. It looks like a folder. Let's run ls. Yeah, you created a folder on my branch. Yeah, so you can keep it as it is. But you... Yeah, I can move it to RM. So this is going to work. You need to add a dash. Okay, cool. Do you do ls it? If you do ls, it should be gone. Okay, then if you do get status, I think you shouldn't get any more. Yeah, perfect. You can commit. Were you able to replicate the whole merge conflict thing? I was having trouble with this thing. Actually, I did it on a different context. Text.cxt. Okay. This is giving me this issue about the new problem. So if I just commit the new problem, then I should be able to continue with the text. Yeah, sure. Awesome. All right, cool. We're almost at the end. Anyone still needs help? All right, cool. I'll just push through. We only have like two more subtopics left, and we're almost more or less done. All right, so next bit is like undoing local changes. So previously we've been talking about like, how do you like commit, commit, commit, right? So like, how do you like undo? So if you like sort of like, fudge things up, how do you undo your changes? So for that, we have the git reset command. So notice that like, just now in the sort of like, the break portion, like three questions, the last one being how do you move things from the wooden box back to the cardboard box, and the answer there was the git reset command, right? So now we're sort of like, expanded a little bit more, and we notice that like for git reset, there are three different flags. So we have hard, mix, and solve. Mix isn't very important. Chances are you'll only be using hard or solve. So the best way to think about it is that the flags sort of like determine like the impact of the reset command. So solve only sort of like affects the head. So in which it sort of like affects like, as far as git is concerned, like which commit you're pointing at. So you can imagine, I'll go into more details there later, but okay, so solve only affects the head, like you're pointed to the commit. Mix not super important, but it affects not just the head, but the index and hard just like nukes every damn thing. So like TRDR, like if you feel that your code is like beyond repair, git reset hard is probably the best way forward. So let's look into a solve reset. So a solve reset allows you to sort of like rewind a repo to a specific commit. So like you can imagine a world where you made like three commits, your three commits deep, you realize that you fucked up and you want to go back. So to do that, we use git reset and then hit followed by Tilda. So Tilda is like the minus operator. And also good to note that the default flag is soft. So if you do not specify, like whether it's mixed or it's a hard, git is going to assume soft. So in this example, suppose I call git reset hit one, I'll go back one commit, which means that it would undo the last commit. Not undo, sorry, it moves the pointer back to last commit. Your previous commits still exist in some form, but it might get removed eventually. Then like by sort of like induction, if you Tilda two, it needs to go back to commits. So to go in front, so to do that, you need the commit ref. So like for example, let's say like I'm here, so I'm in the screen point, I want to go back to this one, right? So that is kind of tricky because like you can't really get this anymore. But if you use this thing called a git reflock, it should have tells you like which commits you're at and then you can actually go back. But PRDR you can't, so like not a good idea. But in any case because it's git reset soft, right? It's a soft reset. What happens is that the index is unchanged, the working directory is unchanged. So as far as git's concerned, the safe has been sort of like touched, but your working directory has not. So like you haven't really undone any changes in the directory. Sorry, so the question is have I pulled the working directory? There's no push or pulling concerns. This is more like you can think of every commit as like sort of like moving things into the safe. So what a git reset does is it pulls those things out of the safe, but like it'll be sort of like moved back onto your various boxes. Also the question is when you git reset, isn't it local or on your remote, right? So like you're usually running a machine, so it's local. So until you push anything, right, it will not be reflected on your remote. Yeah, it's only happening locally. Yeah, so in fact, like if you do something funny, like git reset and then push, right, you'll probably fail because like this is whole divergent thing, right? Yeah, so like just be careful when you're doing all this like soft resets. Any other questions? And it goes back two steps on that. So essentially it's like back three steps. Yeah, so the question is what if I were to sort of run this command, git reset tilde one, followed by git reset tilde two. So when I run the first one, suppose I'm here, I'll go back one. So that's the first command. If I run it, if I run tilde two, I'll go back two. So I'll end up here. Like hopefully I answered your question. So like you can, I guess like sort of like briefly demo that. So notice that in the previous comment, I made, so if I did a git reset. Okay, so nothing changed because like I picked my head, right? So if I were to do it again, what do you think would happen? So the change prior to this was I renamed tree in spelling into the, like the formula form, right? So if I were to run this, let me just do this. So let me just create two comments first. So there's one. Okay, then I create another one. All right, cool. So now let me just do a git reset. Yeah, so in this case, why we didn't really see any changes in the file is because notice that you go back to this diagram. Like the impact of solve is really only the hit, which is like the save so to speak, right? So notice that index is unchanged, working direction is unchanged, right? But if I do this, git diff, it tells me that there was a particular sort of change. So this is, git's telling me that the difference between what was in the save and what is currently reflected in my working directory. So remember like, okay, so this is a nifty command which is git diff. It basically just gives you a summary of the differences between what's in your save and what's in your working directory, your couple of blocks. So notice that previously we did a git reset solve. We sort of changed sort of like the state of the save because we moved it back, right? And that change is reflected when we call the git diff. So it's saying that like, hey, now the save is different from the working directory. And this is like the summary of the changes. Yep. So tldr, when you call a git reset, the working directory doesn't really change, but the save is changed. And to see the changes from that change, you will use the git diff command. So like, nifty command git diff tells you the difference between the save and the current state of your git repo. Okay, so the question is like, if you do the reset, do you do the pull? So the problem is that whenever you do a reset, it's actually quite dangerous because you're rewriting history. So if you're resetting things that have already been pushed, you have a very fun time because now your branch is sort of out of sync with the... It's not just out of sync, it's like diverged from a remote branch. Then you have to do this really dangerous thing called a false push, which basically tells git like, screw the online branch. I want to push my own branch. So tldr, just be really careful what's sort of synced with your remote version. Yeah. But I mean, as long as you're working on your own remote branch, it's perfectly fine because you're not touching master. But if you do a git reset on master, then your team is going to hate you. Okay, so that's the soft version. And then there is the hard version, which is like the Hail Mary. What that basically does is it just nukes all your changes. So like, that's basically when you figure out that things are wrong and it's not worth saving. So it basically removes all your changes and there's absolutely no way of getting it back. So let's be careful when you run that. So like, to give that, to provide an example, let me reset hard first. All right, cool. So let me just make a bunch of changes. All right, so let me make some changes. Let me move it to my cardboard box. Sorry, my wooden box. Okay, so let's say that, okay, there's this in my wooden box. And let's say like screw it, nuk the whole damn thing. So I'll do a git reset. And everything is gone. And there's no way of getting it back. Sorry. Okay, so let me commit that actually. So let's say I have commit two. Okay, so I create a new commit. So this has that particular line I want to like nuke, right? So if I did a git reset, hit, you know, one. So this is the soft one, right? So that will actually wouldn't change this particular file. It will just change the save. But let's say I want to change the save and the file. So I'll just do this hard. And it's gone. Yeah, so TRDR, if you want to nuke every damn thing, just use hard. But if you're not sure, just do soft. And then run git diff and see what changes will mean. So feel that helps. All right, so the last bit is making emerging PR requests. So currently we've only been like sort of like interacting with your own repo, your own version of the online repo. You can imagine like as you sort of like level up your programming skills, you want to like collaborate on projects, you want to contribute to open source projects. So that's where like the whole PR request for flow comes in. And with that, within GitHub land, you do what's called like a fork. So the fork means that you're using an existing online repository as your own starting point. So the main goal of that is two four, right? So others like you want to sort of start your project off like what other people have done. So you fork it, or like maybe you want to contribute back to the project. So you fork it, make your changes, and then push those changes up to the original repo. And then the author, then decide whether to approve your changes or not. So the general flow is as follows. Step one, you fork the repo. Two, you clone it. That means you download it onto your own local repo. Sorry. So you fork first. So for basically sort of copy and paste the repo, such that you have your own version of the repo online, then you clone that repo, meaning that you download that repo onto your local machine. So now the repo exists in sort of like three forms. So for instance, the OG one, second one is the one that you forked, and then the one that's on your local machine. So your local machine is in sync with the forked one, right? Whatever changes they make on your local one, and if you have to push them up, it will be reflected in your clone or forked repo, not the original repo, because you did not own that. And suppose you're happy with the changes, and you are proposing that these changes be added to the OG repo, you'll make what is called a pull request. So let's illustrate that workflow. So to start off, you can start by sort of like cloning my repo. So there'll be here. So if you're to go to this particular website. So we go to here, you can click fork. And if you click fork, you sort of redirect you to a new repo. So we do that. So I can't fork my own repo, but imagine if I were to do some other... So for example, let's say I want to fork this one. I'll just click on this. So I'll fork it. Yeah, this one's a big repo, so it's gonna take a while. So once you're done, you see that like now it's under my name, right? And then like this is particular like forked. Sort of URL. So this is for GitHub to sort of track where the repo originally came from. And like that linking is required if you want to make a pull request on the original repo. So when you click on fork, you'll ideally get this like double links. So the first one under your name and the second one being the OG repo. And then like... Similar to Facebook, you can always like start repos that you like. So like feel free to start mine. Yep. So once you have forked the repo, the next step is to clone it on your local machine. Right? So when you go to that particular repo, so this is the one that was forked, I click download or clone. There's this particular URL. So that's the command you need to get cloned. So like create a new folder or go to like some other folder that's disjoint from your existing Git repo and run the git clone command. So once you've done that, the folder have been downloaded. So go ahead with that. Yeah, so like caveat here, like don't run this particular command. You have to fork it first and then replace this with whatever there was like present in your own forked version of the repo. So like if you copy and paste this in your work, but then like it's not part of the exercise. So like to demonstrate that flow, I already cloned it, right? So I already forked it, it's here. And then I would replace the second half of the git clone with whatever that's in this particular text box. Okay, we're almost there. That's like 10 more minutes to go. So like if you have troubles, like fork in the repo, let me know. Okay, so I already seen like four forks. So like I should be expecting more. Help me bump my fork counter, guys. Okay, so like once you're done forking, right, and have cloned it onto your local repo, we'll just go ahead with like the usual branching workflow. So what happens there is once you have it on your local machine, create a new branch, make some any changes they want, and then push that branch. And like if you're stuck, that's the reason I let us know. Like there are currently like six forks. So like if anyone like stuck, that's a crazy low number. I guess managed to fork the repo. I clicked here, right? So like you have to fork someone else's repo. So like let's go to that particular URL. So suppose you're going to collaborate with like my project. So you just go to that URL, click fork, and then you see it copy and pasted on your own local repo, on your own like get up account. If you guys have been able to Yeah, I'll get checkout dash B. Like you guys managed to clone it? So what I was just saying is you just run that run account. Is there anything you have to do with all this? So you... Which page is this? So have you forked it yet? So the whole purpose of this exercise is to pretend that you want to collaborate with some other project. Or like you want to contribute to an open source project. So you go to this project, my repo, and then you click fork. So what fork does is that it makes a comma copy of this repository under your own account. Because you cannot push through this repo because it's not owned by you. So you have to make a comma copy first. You then clone that one onto your local machine. You make changes, you push it up, and then you make a pre-quest. So you cannot get cloned first than you forked? Because you can get cloned, but then where do you push to? You could do it out of order. You get cloned first, you fork it online, and then you set the remote to this but it's an extra step. It's a bit confusing for a beginner's course. So you guys managed to fork the repo? No, just playing. Are you familiar with the branching? Yeah, I'm branching. I'm on to see the merge conflict. Oh, the merge conflict. So maybe you can open up that. Do you have the PowerPoint slides? Keep going down, all the way down. So this is the conflict-free version. This is the merge one. So basically you just need to create another branch. And on the master branch, you also change line three. And on the test branch, you also change line three. Then you try to merge this test branch into master and then you get a conflict. Because both change the same file, and maybe it doesn't know how to merge the two. So what should I do? Okay, let's say I'm in a master. I do this file here, and then I change a line. Then I add and then I commit. Okay, then I change to the branch. I change the file. Actually, I also can. But when you branch off here, the file would look like this instead of this. So the flow is just like, I'll check out A first. I'll make some change. And then I'll check out master, make the change, and then merge A in. Isn't all of these stored in the same file? It's all stored in the hidden folder. Yeah. The one on the main file, this is actually part of the master or part of the branch? Where your hate is pointing at. So this reflects the current state of the project. So this is my master. Depends where you are. So currently, my guess is you are master. So this is master branch, if you will. But if you check out, say, branch A or branch B, then this will be branch A or branch B's version of the world. Oh, this will be the branch of that version. Yeah. This will be the file of that version. Yeah. So suppose that you have successfully forked the project, and then you have cloned it on to your local machine, and you've made a new branch, and pushed it up. So once you've done that, right, if you're to go back to your forked repository, you'll see this particular, like, sort of like dialogue, which basically says, sorry, compare and create a pull request. So on that bit, you can, it's about to demonstrate, but when you click on this particular green button, it'll tell you whether you're going to create a pull request against your local repository, or against the one that you've forked. So if you press on the forked repository, and you press, like, submit pull request or whatnot, the owner of the repository will get a notification saying that hey, this guy wants to, like, merge changes into his repository. And that's when, like, the whole peer review process, the author says, make some changes. Make a new branch, make those changes, push it back up, and ping the person again. And suppose once the author is happy, and it proves the changes, it'll be merged into his own repository. So that's the whole, like, gate workflow. Hopefully that makes sense. So, like, TRDR, like, once you've, like, cloned the repository or whatnot, like, and you push a new branch, you should ideally reach this particular state where you have that compare and pull request button. Actually, let me just demonstrate this workflow. Let me just grab your repo. My repo, okay. Yeah. Oof, okay, now it's okay. Okay, let's grab your repo. Okay, let me just... Hey, wait, sorry, right? Get the URL. Okay, let me just, like, demonstrate the whole workflow. So let's say I go to my friend's repository. So, like, suppose this is, like, sorry. Oh, goddammit. Okay, so suppose this is the repository that I want to contribute to, right? So what I'll do is that I'll click the fork button. So I'll fork under this account. So what this does is it creates a common copy of that particular repo, but under my name. Right, because I cannot push changes to that particular repo because it's not on my me. So what I first do is I copy and paste it into my own ownership. So now I have the exact same repo, and it says that, okay, this is the OG source. And then now I'll just clone this. So what I'll do is that I grab the URL. Okay, then I... Oh, boy. Okay. Let's go out. Okay, so now I do getClone. Okay, so it's probably a good idea to not, like, getClone within the current project because, like, now you're just, like, adding a new project within the project, which is not what you want. So I move out. Then I do a getClone. So this is the link that I copy and paste it just now. Cool. So now I already cloned that repo. Let me go into it. Cool. So now it's master. So following the usual branch workflow, let me just do a new branch. All right. So let me just maybe modify this file. Okay, so I made some changes. Let me just commit that. All right, so I made the changes. Let me push that in. So in this case, I get this, like, weird error because, like, it doesn't sort of know its corresponding online version, right? Because this is the test branch. So I get this weird error. So in this case, I just copy and paste this code in. So this basically tells that, hey, the online version of test is like so. And with that done, I can push. So let me refresh that. And you see that I now get this sort of yellow dialog. Let me just click compare and compare and pull request. So in this case, the base repository is the one that I originally forked from. So that would be like the OG repository that I want to contribute back to. And where the changes are coming from, they're coming from my own repository, which is the hate repository. So in this case, it is my name, the repository name, and then the branch. So in this case, I want the branch to be test. So suppose I change it to master. Like, nothing really happens, right? Because I didn't make any changes on master. The changes will be on test. Yep, so this is my commit. And then let's see. Let me just search this in clocks. So I didn't create the pull request. So in this case, you'll say like, okay, there are no conflicts. I can go ahead with the request. Then it's now up to the owner of the repository to approve this PR request. So maybe the person can approve it for me. You have existed? How do I accept your... Yeah, go to pull request. Okay. Go to your repos. Click on this one. Go to my first repo. Yeah. Then click on this one. So maybe just add some comments. Then comment. And then click merge pull request. Now, compromise. Thanks. Okay, so suppose the owner is happy with my changes. So in this case, it has been merged. So if I go back to his OG repo. So this was the original repo that I forked. And if I look at this file, I can... So this is all the workflow when it comes to working on GitHub projects. Yeah. So that's the whole PR workflow. So any questions on this one? Yeah, this is kind of hard to demo on one computer because it involves multiple accounts. All right? So if you made it this far, you more or less have the basic skills to interact with GitHub and with that, congrats. So if you sort of made it through this far, you can pretty much work professionally on any GitHub project and with friends. And for those doing 203, congrats, this is pretty much good enough. So there's that. Yeah. So in the interest of time, there's certain more advanced Git topics that I didn't really cover. So once you have pretty good grounding on whatever you cover today, certain topics that you might not look into would be Git rebased. If it's in the safe, it should stay in the safe. And messing with that is a bad idea. But Git lets you do that if you want to. If you want to, and it's called a rebase. So rebasing this allows you to really mark around with whatever's in the safe. There are some useful uses to it, but do check it out. The next one is Git hooks. Sometimes when you do Git commits or Git pushes, you might want to run certain checks. For example, you could have certain tests or sanity checks that should pass before you make any push. Hooks allows you to sort of add that function at the end. Next bit is like stashing, right? So notice that whenever you want to save any change, it's called commits, right? But commits rewrites history or like, it pushes things into the safe. So suppose I want to save certain things that I don't want to be in the iron safe. I can do it in a different box which is called a stash. And lastly is like Git revert, which is a commit that allows me to undo a commit. It's a mouthful. And last bit is like cherry picking, what are the things that you want? So next bit is like quality of life hacks. So maybe after this whole exercise, the terminal line is horrible to use. I have no idea what's going on. There are certain tools that sort of like maybe alleviates the process, makes the learning curve a bit more straightforward, and might provide a better user experience. So two very common softwares that are available are Source Tree and Git Cracken. Source Tree is available on macOS and Windows. This basically provides a GUI interface to Git. So you don't really have to type another line of code, another line of command if you really want that. It also comes with all sorts of fancy features. It shows the changes between different comets, changes between branches, things that can be done through Git but requires way more keystrokes. If you just want to use Git, this is probably one part of your mind to consider. There are also Git tools that can use within your text editors. If you're using VS Code like me, certain plugins you might want to consider adds certain functionalities like it tells you which line of code was last touched by who and which comet. There's Git History Div which provides useful shortcuts to allow you to compare between branches, between past comets, pretty useful. If you use Emacs, you can consider things like MAGIT, and if you use Terminal, you can consider this tool called TIC, which is Git in reverse, really fancy stuff. So with that, I've reached the end of the whole Git workshop. I really appreciate feedback. With that, thanks for coming. I'll be around if you have any more questions. Thanks. Actually, there's not much value at in recording sessions, right? I think there are some people that say they want to watch the recording. Fair, fair. But we're then weird, right?