So today I'll talk about GitHub. So in the previous session I talked about Git, how we can track changes in our source code in our project using a GitHub repository. Now let's learn about the role of GitHub. So whereas we have the source code locally, we can push it to a remote location to kind of centralize it and one of those places is GitHub and it made coding socialize in the sense that whatever you have Instagram, you have Facebook, all this kind of social media, you can think of GitHub as a social media but for coding. So we're going to see what to do in just a moment here. So today I'm going to use this repository, I'm going to paste in the Zoom chat to practice the examples. So once you go to GitHub, you can go to github.com slash explore and you can find out other people's source code. So basically the most basic function of GitHub is hosting or storing the source code of people's projects and when you're able to see other people's source code, that's public and people can suggest changes to it if they wish to do so, that's called open source. That's separate from closed source where you cannot see the source code. All you get is a binary already compiled file of a program that you just execute, for example, Windows is a .exe file and you have no idea how that was built, what's the original source code, that's a closed source. So open source, everybody can see, anybody can propose changes and contribute. So there are different ways you can go about GitHub. If you're somebody who wants to suggest changes or contributes to an open source project already written by somebody else, that's maybe hosting on github.com or if you're working in a company and the company itself applies GitHub to host the source code, but it's within the private setting in the sense that only the company employees have access to the source code, but not the people outside. So usually they call that practice inner source where they kind of employ the practice of open source, but within the company only source, so it's kind of inner source. So I just want to point out there are competitors out there to GitHub and it's similar service if you have a hard get lab at lashing, Bitbucket, Azure Dev Officer, Microsoft and so on. They're all similar things, they do the same thing. Okay, now let's say I'm browsing GitHub and I found a project that I'd like to contribute. Maybe you have a favorite project that for some reason is open source and maybe you can contribute in different ways. You can just change a type in the documentation that you read somewhere or if you're more advanced, you can do some coding, you can go through their source code, fix the bugs or you can even propose new features. If you use the program, you like it so much, but I wish I had this feature, I can go there and propose it. Now in order to do that, first you've got to find a project which is called a repository. We have Git repositories locally, but they're also called repositories on GitHub and they're usually namespace under an owner. So if you see like nest.js slash equalize, so the repository name is SQLize and that belongs to the owner nest.js. It's probably in the case of GitHub, it's either an individual person or it could be an organization. So if I click that nest.js here, it's probably an organization and it has many, many repositories and if I go back, click SQLize, that's one of their repositories and I can see here the source code, all of the files and I can go and have a look, okay, this is what the code is like and browse everything and so on. Now if you want to contribute to this, what you want to stay in is usually the issues tab. So there's a task to do or people can report bugs and that kind of stuff. If you go there, this one doesn't have much, but usually either people have some question or whatever they should put in the issues as well. You see this one dependency dashboard has some things to do, so usually there's a title and there's some description about what this task or issue is about. And usually if you're in the open source setting and you want to contribute, usually you don't have direct access to the permissions to change the code. So what you have to do is usually you have to comment here, hey, I would like to help out with this task and then once you comment that the owner of the project will be able to see you and if they wish to do so, they will go ahead and assign you to this task. Now we're going to demonstrate how to do this with our thought story here. So this is the report story in case you haven't gotten a piston in the Zoom chat again. So in this case today, I have this report story. Let's make believe it's some project that you would like to work on or contribute. So if you are open source setting, usually you want to have a look at the issues. I've got some issues to do and find the issue that you want to tackle. If you don't have an issue here that is associated with whatever you want to do, maybe you have a bug report, usually create a new issue there, put a very specific title and describe the issue, add steps to reproduce if it's a bug, add screenshots if you need or even videos. Whatever is evidence you have to give proof to what your issue is about and then you can click to create and it will be created. For example, this issue that I created here is to create a file. First you want to read the title, create a file of your user to handle, write what your learning interests are and then have a look at the description to understand what needs to be done for this issue. If you understand it and it makes sense to you, you can comment here asking, I'd like to help out if it's open source. If it's already an issue part of your company internal issue, you already probably have permission to this so you don't even have to comment because it's your company, you're part of the company, so you can just assign yourself here or your manager would assign you here. It's not clear to you what the issue is about, you need more clarification. That's when you would also comment, hey, I don't understand exactly what you mean by X, could you elaborate? Then you can start the conversation here, click comment and then the other person, the other party will reply. Usually you can tag them if I would go back to add on my issue. If I would to do it over, I would do it CC, whatever the person name here is on GitHub. They usually start with the add sign and their username, something like that. This would point to the person here. Since I don't have anybody associated with this particular repository of that name, it doesn't show anything. All right. Then the other party, assuming I'm using myself, it'll be another person. Hey, I meant to be like this and that. Okay. Then you go back and forth talking to the other person and so on. You get the point. Anyway, once you comment here on the open source setting, the other maintainer will decide, okay, I think this person can help out. They would go here and click assignees and click on your name. Okay, I want this person to do this. If you're in, like I said, in a company, you probably can do it yourself or the manager would assign you. Now, if you guys want to try to comment out on this, I post the link there if you want to comment out. I want to help out. Hey, I'd like to contribute. Thank you for posting that. I would see here, okay, this guy wants to contribute. I would assign the person here. You can see your name now appears after you comment in the open source setting, so I would assign you here and then your name appears. Now, obviously, it would be one person at a time, usually. I just put myself here and another person who is participating just for the sake of example, but usually you want to have just one person assigned to the issue, otherwise you have two people at the same time working differently on the same thing. That's not efficient. You're going to waste time, so make sure at the first comment asking you want to help out and then once you are assigned, then you can start. Don't start before being assigned because it's not usually a good thing. Nobody knows who's working on what. All right, okay, so once you're assigned there, usually what we also do is add it to the project board. That's one of the features that GitHub has and that's also present in other systems like if you ever heard of JIRA, that same kind of thing. Usually it's under this project's wheel here. You can click the wheel and choose which project board you want to place this task. In this case, I already have one, so I'm going to put it in this one, seduction to get. I can click the check mark, click outside. Now it's going to show some status here. It's to doing progress or done and we're going to see what that means in a bit, but usually I want to put in thing to do and then I'm going to move it to in progress later as we see the board instead of doing directly here, but you could have done it here. That's totally fine. I'm going to go here to this tab called projects. This project, I made it visible publicly, so you should be able to see it if you click projects and click this one. If you can't see it, just place the link there. As you can see here, this is like a team board in the real world. It would either be the open source projects one if they have one or the team board. You have different people working on different things so you can know what's going on right now just by looking at this. There's usually a column for things to do, for in progress and for done. You might see other additional columns depending on your workflow in the team. There might be an in review column where people have their full request there, the proposed code changes. There may it might be a column for things that you don't plan to do right now. Maybe it's called a nice box, something like that. That depends on your team. As you can see here, that one that was assigned to me and the other person who's participated is entered to do column. Once you're ready to start on this issue, after being assigned, you want to move that to the in progress. Like I said, you could have done that from the issue page or you can go here and click and hold the mouse button, drag and drop to the other column in progress. People will know, okay, this person is now doing this. Usually the moment this would be brought up in the company setting is in stand up meetings. Usually they could be every day or every other day depending on your team. Everybody in the team meets to give a status of what you have done, what you're doing right now and what you plan to do in the future. People would usually bring this up and see what everybody can go through it and see how everybody's doing, what's the status of what you're doing, do you have any blockers, do you need help, something like that. Okay, so once I did that, I can start working on the issue and you can see I'm also working on teaching a lesson, which is what I'm doing right now. Anyway, you can either click here or go back to with the browser back button. If I click here, I can also see it like this. Thank you for another person. I will add you to here. Just make believe there's only one person, so I'll add you there. Okay, so we are ready to start on this issue. I have read the title, I have read the description, I have asked clarifying questions and I'm good to go. So I need to create a file with my user handle and then I need to add whatever sentence with my interest. So once I got that down, I would go to the code, let me go back here, code tab. So to do this, there are different ways, right? You could do within the GitHub interface itself, the web interface, but that's very limiting. So we actually want to do that in our local machine using our own text editor. Before I do that, anybody have any questions so far? Let me know in the chat. If nobody has any questions, I'll assume you're good and I'll keep going. All right, so let's see. So in order to take this and edit these files, if you are in the company, you'll usually have direct permission to change the code here. Now if you're doing open source, what we have to do is what's called a fork. Now fork is just a copy of the repository that's placed under your ownership. If you see right now in the top in the breadcrumb here, we have MBK Tech World, that's the organization or the owner of this repository. And that's the right hand side, that's the repository name. Now if I'm just a stranger to this, I'm not a maintainer of this project, I cannot just change it. So what I have to do is make a copy and put it under my ownership. To do that, you click the support button here. Now keeping my forking is a feature from GitHub.com itself. It's not a git feature. If you want to simulate this with just git, you would have to copy the code, basically clone it and then create a repository under your name and then push that. But since that is all taken care of behind the scenes by GitHub, we don't have to do that manually. So you just click this fork button and it will ask you some, what's the name you want? So I'm just going to use the same name under my user and I'm going to click create fork. So it's doing its job, copying the code and everything. Okay, now I have my own copy of that project. You can see here, it's under my name now, mbk-hope-slash-indroduction-to-get-to. And it says here forked from. So I can click this to see where the original is. Okay. In any case, now that I got my copy, I can change it and I can either change the web interface or using my local computer. To change it locally, I can do click code here and I would choose either HTTPS or SSH. I already have SSH set up. Now we looked into how to set up SSH in the previous lecture. So I'm not going to really talk about that, but if you want to do that later or ask in the squad, you can do that and we can figure it out there after the lecture. Anyway, you can also click to download zip if you're not sure. That one doesn't really tie to the repository here, so it's not really good. Anyway, I'm going to copy this URL here, then I go to my terminal and make sure to create a namespace directory for the ownership of this. Right now I'm in my organization, which is not really what I want. So I'm going to cd.dot to go to one level up and I want to make sure to have my own username directory here. Usually you can do MKDRR if you don't have one with your username. My case is mbkhope and I already have it, so if I cd to that, you can see it's here. This should match, it's a good practice to match whatever you have on GitHub. If your GitHub username is that, then you can do the clone here. Get space clone, space that link, and then enter. And I already have it, so I think that's why it's complaining. There you go, it's here. So the reason I have the namespace of my name here is so that when I cd to it, cd-introduction-to-get-to, I know exactly that this copy is from my ownership, which is different from the other one, mbk-tech-world-slash-introduction-to-get-to. So I might get confused if I clone them and don't have like a hierarchy in the file structure to tell me in my local where exactly I am, who's owners of this. So that's why I always have the namespace directory before my repository name. Any questions so far? All right. Okay, let's keep going. So once we clone it, we are going to, let's do, somebody asks, this fork can clone the same thing? No, so let's go here, the GitHub. So cloning a repository, clone is like a get command operation. That just means you're, it's kind of downloading the repository from a remote location. In this case, it's on GitHub here. So I want to pull all this repository and put in my local machine. So I do a get clone. It's like downloading it. Now fork is another thing. Forking is when you have somebody else's repository on GitHub, working as a GitHub feature. And I want to make a copy of this for myself because it's an open source repository. Anybody can make a copy. So I would click this fork thing, see fork your own copy. And it would basically copy and paste the code, but it's actually creating different repositories, right? There's the nbk.tac world slash introduction to get to. And then there's the separate repository, nbk.hope slash introduction to get to. Even though right now they have the same code, they're different things, different repositories, okay? Under different ownership. All right. So. Now that we got it locally, let's open it in the text editor. You can use whatever a text editor you have. I use visual studio code so I can just type code space dot dot means current directory and I should open visual studio code. Let's see. Here it is. You can click explore and click test. This is the file that was already in the repository from the previous lecture that we just typed some stuff there and made some commits. But my task right now, remember, my task is just to create a new file with my user handle nbk.hope from GitHub dot txt. And say I'm interested in learning Git and GitHub. Just put whatever there. Save that. So usually you would go about, you know, real setting when you have like a lot of code, you would figure out how to do things and then you would start making changes or additions or subtractions through the code. And then you would add that. Remember, get add. And then finally, you would do get commit. And then you keep repeating that as you're going about your changes. And once you're done, you just push to GitHub. I forgot to say usually we don't. We don't work on the master branch, which is the main timeline, we would usually make feature branch which is with branch off of the master one or a main one. And then you work on your changes there. And once you're done, you would merge back into master, but you would merge through GitHub through what's called a poor request that we will do later. In any case, let's create a feature branch here. So instead of me opening a new going back to a terminal window here for the sake of convenience, I'll just open from visual studio code. If I press control, back tick the key next to the number one in my keyboard. I can have a terminal here. I'm using windows right now so I can choose between PowerShell command prompt or get bash. If you're a Mac, you might have different choices or Linux. Anyway, if I choose just a command prompt, that's simple for me. What I want to do here is first I want to situate myself. Now we can do this visually as I'll probably show you later, but let's recall the get commands. So first I want to situate myself and get space branch to know what branch I am right now. I can see the stars next to the branch. I'm currently checked out and that's the master branch. Like I said before in a previous lecture, you might also see this as the main branch. If you do like your own repository and you're using like the latest version of Git because they have changed the names of the default branch. Instead of saying master, they now want to use main. In the case of the same thing, the default branch. I'm a master, but I want to create a feature branch because the master is supposed to be something that's always stable code. Nothing is broken there. It's not supposed to be stuff under construction there. That's the code that's always in production running. To prevent any problems, we're going to create a new branch. So to do that, get check out. Now dash B to create a new branch. And then the new branch name. Let's see add sentence. That's the name of my branch. I usually like to name my branches lowercase, separate the words via dash. Although you might see other people having other naming conventions. I think this is a very good one. In any case, press enter. If I do get branch again, I should see that the star is now next to add sentence. Which is my current checked out branch. So with that, I can start working on my changes. Okay, I think I'm good. So I'm going to do a get status. I can see now there's an untracked file. That means get is not keeping track of this file in version control. So we first got to get add the file name and then do a get status. You can see now that the file is staged. That means changes to be committed. Remember, when we do get is always a two step process to make a commit. First, you have to add to the what's called the staging area. So that you can verify everything's good before you can make the actual commit. So I think this is good. Before I didn't do a get diff to verify what I did because I already have the editor open here. So I know exactly what I changed. Anyway, I think I'm good there. I'm going to do get commit. And I usually like to add the message right away instead of opening text editor. So I'll do dash M for message and I'll say add sentence. And then usually you want to say a brief message that's very specific and descriptive of your change. Maybe add sentence about what NVK hope is learning. And then once you're done, enter to make the commit. Now I can see if you do get log that that commit has been added there. You can see that there's the commit shot or hash and the author, the date and the comments. And you can see there's other comments in the past. Q to quit if it's too long. Press the Q key and the keyboard to quit. All right. Okay, then you would go and keep doing stuff. Maybe you made a typo here. I'm interested. Maybe you want to write something else. I also like JavaScript. Maybe you forgot to say that. So I save that. I can see now that I get status here. I can see it there. There's a change. You can repeat the same process to make another commit. Okay. So usually your work will involve multiple commits, not just one. Now, before I do that, I don't want to do it in the command line because I want to show you can also do that visually through the GUI graphical user interface. In my case, it's visual studio code. If you're using a different text editor ID, they probably have the same extension for version control. In visual studio code, there's these icons on the left hand side. Usually you can click the version control one source control. It's supposed to be a main branch and then the branch off feature branch icon. That's what it means. So if you click that, you're going to see this showing the file changes. And this is basically the git status on the command line. It's saying, okay, we got some changes in this file. So if you do click it, it's actually the git diff command in the command line. So you can see right away in red color means it was removed the line. And then the plus with the green coloring background means you added that. But in practice, if you click here to show leading on trilling white space or whatever function, it just means that I added one more sentence there. Okay, so if you're satisfied with this, now we can stage it, meaning you can git add to do that simply go here, select the file. When I add, click the plus icon. You see it says stage changes. Same thing as doing git add in the command line. Now, once it's stage, you can click it again to verify once more. Okay, are you sure this is what you want? If you're okay with that, we'll proceed to git commit. Now to do git, get command visually here. There's this message text box. There's the commit button. So type the descriptive message for the commit here. So I'm going to say mention. I mentioned that mbkhope also likes JavaScript. So something specific and descriptive of the change. Now click commit. Now you can see now it's been committed. If you go git log in a terminal, you're going to see it's there. Mention that also likes JavaScript. Okay, so that's the same process, but visually if you like doing that better. I would suggest you do everything by hand in the terminal until you get comfortable with that. You can proceed to do it visually through the graphical user interface because you already know what's going on behind the scenes, behind the 3D graphics. Okay, I think I'm confident that all my changes in the branch are ready to go and be merged or proposed to be merged to the master branch. Now what we got to do now is push or it's kind of like uploading the changes to GitHub. So if before I do that, let me just check my remote. So git, space remote, space-p, and I can confirm this repository locally. It has an origin remote. That's just usually the name it's given. And it's pointed to mbkhope slash. This is my username. So you want to check here that you're actually working on your fork and not the original one because the original one, if you try to push, you don't have permission. So that's why I'm checking. This is my origin. This is not the origin. This is my copy. Therefore I can push. So I can do git push. Now I want to push to what remote? The origin one and then space. What's the branch you want to push? Well, I want to push the master branch. If you have main, that'll be main here. Now, usually when we do this, we can also add the dash U option between the push and origin keyword to track this branch. So the next time we push, it would not need to say origin and then master. Now, mind you, I put master there. That's actually wrong, right? Because we're working in a feature branch, right? It's add dash sentence. I shouldn't put master here. That would push master, which is already up to date. So I would actually want to use push origin and add dash sentence. So I press that and you can see it's now set up to track origin slash add senses. This origin slash branch name prefixes the remote one usually. So when you see the slash there and origin slash, it means the remote branch in the origin remote. And the add sentence is the local. So they keep the two copies, the remote one, and you have the local one here. So to make the distinction, you need the origin slash prefix. In any case, let's go to GitHub now. And if you refresh or it's probably already here to see add sentence is a new branch here. If you click this branch selector, let me refresh because it's not there. Branch selector here, it says now there's one called add sentence. I can click that to browse. And that one has the new file here. See the file? I can click that. And it's exactly what I typed locally. Now going back. Now this is just for my copy, right? I need to propose changes to the original. But before I do that, let me know if you have any questions. Okay, it looks like everybody's good. Now what we want to do now is called pull request. Now pull request is just a means on GitHub. It's a GitHub feature that we use to propose code changes. If you use GitLab, they call it something else like merge request. If you use another service that's not GitHub, they would probably call it something else. But in the end, they're all the same thing. It's a similar name, same feature. Okay, I can either go to click pull request tab and then click new or GitHub makes it very convenient that it just has this yellow banner here and it detects that you pushed a new branch. So I can click confirm pull request. Now let's read what this means. You want to read from right to left, okay? So reading from the right, okay, you have the add sentence branch on your copy. This is my copy, right? You have my username slash introduction to get to. Okay, that branch is going to be merged into the one on the left, right? This is the master branch, the base branch, that's what's called, of the original. NVK tech world slash introduction to get to. So that's correct. We're merging our own copy, our forks, feature branch into the master branch of the original. Now, when you make a pull request, you want to add a title and a description. Now, usually you want to make it very like a title that's brief, but very specific, so that the other person who will take a look at this understand right away what you're proposing. Otherwise, if you don't write anything, nobody will understand when they look at it. What is this? They have to look at the code, take a long time. Some people, especially if it's open source, they might even ignore it because you didn't say anything. And even in the company setting, you might be working other people and they have to review it and they might not like it. Hey, we didn't write anything. So are you expecting me to waste all my time, spend the whole day trying to understand your code, what you're trying to do? What's this associated with? What's the issue you're tackling here? Okay, so you want to be descriptive here. Anyway, add a sentence for MKO, my username, saying, mentioning his interests. And then I will go on to describe it in depth because this is very silly and simple. I don't have much to say, but I can try to explain you what I did, like my thought process. I considered this option and that other option, but it didn't work out. So I opted to do it in this way. And then you're going to explain, okay, if this fails, this is how you can recover from this. Maybe you have a kill switch, a feature flag. And you have to mention all these things because other people will have to read it. Somebody, maybe you or another person will deploy this and maybe they're going to have some trouble. So you have to tell how they're going to get out of trouble, you know? What's the mitigation work around? All this stuff must be written here. Anyway, I created a file with my user handle and wrote some sentences about my interests. There's not much to say here. Should be, should not be a risk since it's just documentation or whatever, stuff like that. In case anything happens, you can just, I don't know, do whatever. It's very silly, I don't have much to say, but in the real world you'd say you can just revert to commit, something like that. Or just push and deploy a new fix. There's no rush since nobody will see it. Anyway, you keep going like that, add some screenshots that's very useful. If you're doing something visual, screenshots are very helpful. Other person will have a look at the image and understand right away what part of the product that you're working on. And if you want, you add a video. I like to add a before and after pictures if it's like a user interface change and all these good stuff. Anyway, once you're done with that, I can click Create Poor Request here. And then the code changes will be proposed. You can see here the files change tab is the files before and after. I didn't have this file and you can click this here. And that would be different. Usually there's multiple files that you have to review and so on. And if you click this gear, you can change between you define a split view and click Apply and Reload. A unified just means everything's together instead of before and after on left and right-hand side. So I'm going to move back to split view. And it can also check hide white space that's very useful if you have a lot of changes. But it's just changing space in every line. Usually that generates a lot of noise if you just add space on the left or right-hand side, like you know, trailing spaces and lines. It generates a lot of diff noise, difference noise. It's hard for the reviewer to come and look at it. What did you change? It doesn't look like you change anything. So they would use the setting and it would just highlight the space changes so they would know exactly. Oh, just add a space. That's fine. It didn't change anything in the lines other than the space. Okay, I'm going to click Apply and Reload. And going back to conversation here, I'm going to look at the questions. Somebody asks, how do you have the changes in the feature branch synced to your local master branch? The feature branch synced to your local master branch. The feature branch I created locally right now, right? So it shouldn't be in a remote yet. So what I did was I pushed. That means kind of like uploading to my GitHub remote, my personal one. Now, if you want to do the other operation that's called a fetch and merge, in this case, I don't have anything. There's no other person working on my fork that's changing my own code base. So it wouldn't really apply. But if you actually did, you would have to make a git fetch and then git merge origin slash feature branch name. Anyway, maybe I can demonstrate that later. Let's see. Or right now, let's see. Anyway, let's first change roles here. So I am here. I am ready for somebody else to review the code. So usually somebody else would be assigned. If you work on, there's a GitHub feature that you can get assigned automatically. A review would be assigned automatically based on the team and the code base ownership. But since we don't have it, usually if you ask, you would go in your, you know, either your team board, you would move that to some column that would signal other people that it's ready to be reviewed, or maybe you go on a team chat like Slack and ask, hey, this is ready for review. Please review my code. And then they would look at it. And usually if they're reviewing it, they can add their name here. And since I cannot review myself, I cannot choose it here. But anyway, another person would review. Typically, you want to have a separate person review your code instead of you doing it yourself. Of course, there are exceptions. If you're working in a startup environment, don't have many people or you're just working, you're on your own, then that's the exception. But usually in, like, if you have enough people, you want to have them review your code. Anyway, let's assume I am the other person reviewing. I know it's my own. I would go here, you know, my name would be here in the reviewers. And I would go here. Okay, I read the title. I understand what it means. I read the description. And then I click to see the files. That's why it's important to have a good title and description so I understand right away what it means. Otherwise, I would have like, okay, I didn't understand anything. I have to look at the code. It might take a while for me to review. So I'm looking, okay, great. If I don't like this, I can go here and comment, click this plus. Maybe could you provide one more sentence? And then I would click either start review or add single comment. The difference is that if you click start review, it will save the comment and they'll only publish when you say publish review. If you add single comment, it will be posted right now. So if I click start review, it would be pending until you finish everything because there'll be a lot of files usually and they would make many comments. And then once you're done, you can click here to finish your review and leave a message if you want. I had some comments that I'd like you to address if you don't mind. And then you click submit review as a reviewer, and then it would appear here in the timeline for the port request. And then you as the person who wrote this proposed these changes, you would go here, okay, could you provide one more sentence? Okay, I would do that. So like I said, let's do the example you were asking, how do we pull changes to our local? So usually I would do this locally, but since you asked how do we sync from GitHub to our local, let's do everything through the GitHub web interface. So I'll go to code here. I would make sure to change it to your branch. Actually, this is not my copy, right? So make sure you go to your copy. So to do that, maybe you want to click the fork here, view existing forks. Don't create a new one. Okay, this view existing. And I can see mine is here. And I can go there. Now I'm in my ownership. Make sure you're on an ownership. Another way to get here is either type in the URL or you can go click your username, your repositories, okay. Anyway, I'm here. Okay, I can change this one, click the branch selector. Here's add sentence. I'm going to go to my file here. I can click to edit. And I'm saying I am also considering type script. And once I'm done, I can click commit changes. If you want to explain what you did here, add sentence about type script and any further description you can add. I don't want to do it. So make sure you commit directly to the add sentence branch, commit changes. And if you click history here, you can see this file also has this new commit that I just added. So what I just did through the web interface is the equivalent of, you know, doing the get changing the file in my text editor, get add, get commit. And I'm just seeing the log now, get log through the web interface. Anyway, going back. So once I made changes to my branch here, it's already going to be reflected in the pull request, you don't have to do anything else. So if I go to the original through this link fork from here, I can see in the pull request tab, this one. I can see my file changed. I have my third sentence already here. This is because the band, the branch is tied to this pull request when whatever new commits appear in the branch will be reflected here. So I can click commits here and these are the commits included in this pull request. You can see the one I just did is here. Add sentence about type script. I can click that to see that I added this third sentence. Okay. Now you ask, okay, how do we sync locally? Now, if I go to my local, right? I still have the old version because the commits are on GitHub, not in my local. So to sync it, right, you have to first fetch usually it's called pull the changes. That's a shortcut get pull, but you can do the separate operations, which would be get fetch. And fetch means like kind of downloaded the latest changes. It's like updating your local, but it's not really going to apply those changes yet. That's why you want to merge. So you do get merge, but what do I want to merge? Okay, make sure you know what branch you are right now. Let's delete this. Say good branch. Okay. I mean add sentence. I want to take the remote add sentence and merge that into my local, which means take whatever new commits in the remote and apply to my local. So get merge space origin slash add that sentence. Origin slash prefix means, okay, this is the remote add sentence branch, not the local. So I'm going to take the remote and merge into my local, which is the current branch add sentence. Once I do that, you can see one file changed. And if I look at my text editor, I can see the third sentence is there. Okay. So that's how I sync locally. If you change elsewhere, I simulate a GitHub that would probably be another person working on the same branch and doing their thing. Although that's not really recommended. You know, everybody will work on their own branches and doing different tasks. So if you're working on the same thing, you might get complex. Anyway, any questions so far? Okay. So with that, going back to forecast, let's say I finished making the changes according to the feedback. And I'm here, I have this comment that I addressed, I can click resolve conversation. Okay, so with that, going back to forecast, let's say I finished making the changes according to the feedback. And I'm here, I have this comment that I addressed, I can click resolve conversation. All right. Thank you for that. And then like Azim said, yes, that's what I, once you're ready to review again, usually on GitHub, you can click this re request review here icon, which would be to the review and then they would be pinged hey this person made some changes. They're ready to review again. So you as the reviewer come in. Okay. I see a new commit. Oh, I see he added the third sentence. I think it's good to go. Therefore, I can click here and click approve and click submit review. Now I cannot do it myself because I created this, but like Azim did there, you would do that, click review and approve. And then looks ready to merge something like that. Very good. And then now it's ready for the code to be merged into the original. Now the merge operation here might be done either by you or the maintainer. If you're doing open source setting, usually the maintainer of the project would do it, click merge per request. If you're doing a company, it could be either one. You know, I've worked in companies when the other reviewer would merge. I've worked in companies where I would merge it myself after getting approval. So that depends on how they're doing in the company. Anyway, you can go and merge and merge. Now all those commits will be added to the original. Now make sure to delete this to clean up. So the cleanup process is delete the remote branch feature branch and then you go to your local here. Now because I'm doing a fork, it's a little bit stuff that we have to do here because if I just do get checkout, let me just focus on going back here. Let's backtrack a little bit because we're not doing direct ownership that might involve some more extra steps. So I cleaned the remote, but I make sure to bring my local. But before I do that, I just want to show you that we are in the original one. If I click code and click my name here, I should see I'm here. Okay, this is my file. Now if you have other pull requests, let's do the other person. Your interest to demonstrate again. Okay, this looks good. I am reviewing. I put my name there. Okay, I read the title of the description. I understand the problem. If I have questions, I can ask here in the comments. Otherwise it can go to the review. And if I had comments, do what I did before. Okay, otherwise this is good review changes approve. Looks good to me. Click submit review. And then you're approved. And like I said, I think it's good to go. I will merge this. And then usually you can clean up, delete the branch. Okay, this is merged, which means I'm going to also see a Zim file here. I'm interested in learning react. Okay, this is all great. The original now has it. But if I go to my fork, let's go to my fork. Click this Chevron here. Click my existing one. You see my fork is behind the original. I don't see any files here. So we got to sync it. Now to do that, I can do locally on GitHub. Let me do it locally. That's what I usually like to do. Locally in my visual studio code. In the terminal here, what we have to do is add the upstream remote. If you have like a fork, the original one is usually called upstream remote. And your copy is the origin one. So if I do get remote dash V as C origin. So let's add the other one. So get remote add upstream. Okay, and then space. Now what's the link here? You can either copy from the page of the original or do it by hand, following the same pattern. I could do it by hand, but just for the sake of showing you go to the original. Make sure it's the original mbk.tech world slash click code and copy the URL here. I'm doing SSH. Going back to terminal, paste that. Enter. Now verify get remote dash V. B means verbose, so it shows the URLs. I can see this is the upstream and it's pointing to mbk.tech world, which is the original. Okay, now I want to do get fetch. Now which one I want to fetch? Well, on fetch upstream, which is the original because it has new changes. Now I want to do the following. Okay, I'm in the branch add sentence, but that one is gone, right? I don't need it anymore. So make sure to first check out master, switch to master, get branch. You can see I'm in master. You don't need add sentence anymore, but before we delete it, let's just get merge upstream slash master. Because upstream is the original, it has new commits slash master. Make sure you have a slash, no space. Okay, I took the upstream, the original master branch changes and apply to my local copy, my fork master. And I can see my files here, file explorer, I have a zines and my own. Okay, I'm updated locally, but not a GitHub yet. Therefore, I have to do what? Well, I have to get push origin because origin is my fork on GitHub and then master to update it there. Okay, so we took changes from the original, merged into our local master and finally pushed to our forks. Remote on GitHub. Okay, once you're doing there, delete the add sentence branch because it's no longer needed. Get branch dash D add that sentence, be careful. Don't delete master. Delete the feature branch. Okay, if I do get branch again, it's gone, it's cleaned up. Okay. Now, good cleaned up branches did the future. Now, something I forget to say, remember the board, if you're working on a team, going back to the board here, project bar in the original, usually in the progress, something I didn't mention is let's see here, if I go back to the issue here. This is issue number what? Number two, right? Because I see the number number two. Something we usually do is in the pull request description. Let me go back to my pull request, I click to edit here. I should have done it in the first time. Okay, usually we say something like resolve hash, and then the issue that it resolves in this case, number two, right? So that way, it's tying this pull request to the issue. So they're linked together. So this one, I know, okay, the reviewer will understand, oh, you're tackling this issue. And then I also link them together here, so that you can see here on the right hand side, successfully merging this pull request may close these issues. So I click there. And this is the issue I was tackling, right? And right now it's complete, but still open. So what I have to do is I usually go here. And if you want to leave a comment, feel free to do so. Usually, you could say, like, I tested this in production, everything's right, or we launched this, something like that. Or, then click close. So it means it's complete. And if you look at the board, it's now been moved automatically to done. It's like an automation for GitHub. But if you didn't have that, let's suppose bring it back to in progress. Suppose it didn't happen, you would go in here and bring drag and drop to done, okay? If it doesn't do automatically. I think there's an automation set up here in this board that if you look at the settings, that does all this moving automatically. Anyway, I think my lesson is almost over. So I'll move it to done once I finish it and make sure to close the issue as well, because there are two separate things usually. But it looks like there's also an automation to whenever I move something in the board, it closes it when it moves to done. So there you go, it's here. Anyway, so that's how you go about elaborating and proposing changes to GitHub.