So, I have this GitHub repository here for the bootcamp, and this is where I've been keeping the source code for all the lectures so far. So you click SRC directory, all the HTML, CSS files are here. And I want to use this as though it's an open source project so we can contribute to. So that's what we learned to do today. So in a previous lecture, we learned how to use the get program to version control project so that over time we can see and track the changes in software source code changes. Then we learned how to push that source code repository to GitHub. And we created our own GitHub repository and synced with the one we had locally. Today we're going to learn how to help on other people's repositories. Before I do that, let me give you another overview of GitHub again. Like I said before, GitHub.com is like the social media for source code and developers. Basically, imagine when you're Instagram, you're looking at people's pictures and commenting on them. When you're GitHub, you're actually looking at other people's source code and programs, and you can comment on them, you can report bugs, request new features, you can even propose changes to the source code so that if you like to build certain feature for software that you like, you can actually propose that. So it's a very powerful thing and there's a lot more to it than just that as well. So if you go to GitHub.com slash explore, you can see many of people's repositories. For example, if you're interested in the Visual Studio Code, which is the text editor that I use, you can search here at the top, and it's actually an open source repository for Microsoft. And you can actually look at a code for your Visual Studio Code here. These are all the files. If you click the issues feature, you'll see all the issues, which is basically people can report bugs, request new features, et cetera, et cetera. There are many tags that you can add to an issue to kind of be more specific about what that is. And you can click any one of them to read the description. So this is the title here at the top. This is the description. And I'm telling you that because in a previous bootcamp, people are confused. I told them, can you create a GitHub issue with this title and this description? And they didn't know that this is the title and this is the description. So that's what it is. Anyway, you can see a timeline of what's going on here. They added the labels and who's assigned to this and other stuff there. All right. So this tab full request is basically proposing changes to the source code. So you can see here, people have been proposing changes. If you click one of them, there's a title just like issues and a description about the changes. So when somebody's proposing a change to somebody else's source code, you got to make sure to be specific and describe what you're doing. And also usually it points to an issue that already exists. That's that it's tackling. This one doesn't seem to do so. So it's not not very good on that front, but you can click this tab file changed. And you can see the before and after of their changes. So that's where they're proposing. It's a lot of stuff. Now, obviously, these are just proposals. Doesn't mean that it will be merged into the actual code base. So that's up to the maintainer of the project to do the maintainer will decide whether to accept that or not. And you can see here, there's been a reviewer. Somebody who took a look at the code and approve or not. So this person here approved the scenes. So it's actually going to go in. But if you scroll down here, there's also this nice feature that you usually see in per request, which is some checks that are run. And this has to do with continuous integration and employment CICD. And basically, every time you propose changes to the code, you can set up some tests to be run and check if what you're proposing is like, doesn't have any bugs, any problems at all. Seems like one of them failed, which is this code OSS check that you can click details and learn more about that. All right. But nevertheless, you can always add comments here and participate in the discussions. It was like you're doing social media. But enough of that, that's the overview of GitHub in a nutshell. There's other features that we'll see later. Now I want to go back to this repository. repository here for the bootcamp. This is where I have my readme and the source code. So if I click issues here, I have a bunch of issues to do that I would like. And one of them is this one, teach get and GitHub, which is assigned to me. So when you've got an issue, you can be assigned to it through this part here. And basically, this is what I'm doing right now. So if you want a different view of this, typically when you work in a company with a team of other people, you're going to see typically a combo on board like this. If I click projects, I have this board that I created here. It's public for you. If you don't see it, let me know. I'll paste the link. So basically, we usually have a to-do column in progress and done, then there could be other extra columns. Basically, you would add a lot of issues here from many different people that are assigned to it. Right now, I have this issue, teach get and GitHub. That's assigned to myself. So typically, we have what's called the standup meeting that we do nearly every day of the week. That you're going to state what you did, what you've been doing, what you're going to do next to your whole team as a whole. And then that way, the manager looks at this and they know who is working on what at any point in time. They just can reference this board. Okay, so my teach get and GitHub issues have been dragged to in progress. So before that's usually to-do. So you're going to have a bunch of items to do that you can add here. I can either click here to add. And if you know the number or name, let me see if I type anything that comes up. No, I type one. There you go. If I type, there's all this stuff here. But there's another way of adding issues there. So basically, you move to in progress when you start doing that. And then once you're done, you move to done. Okay, well, let's pick an issue to work on. So if you're interested, I'm going back to the list of issues. So if you're interested in contributing to open source, or if you're working in a company setting, you're going to have a repository of the thing of interest, in this case, this one. And then you're going to go to issues, or it could be also offloaded to another website like JIRA from Atlassian, or some other service for item tracking and task lists. But anyway, so you're going to find something you want to work on. If you are working in a company, you probably already know what you're going to work on because it's been assigned to you beforehand. Maybe you met with the manager and said, hey, I want you to work on this project, this water. And this is the epic of all the things we got to do, the business requirements. And from there, you can build and create new issues accordingly. If you're working in the open source setting, like you have somebody else's project that you admire and would like to contribute in any form, you would go here to their repository and issues, and then you're going to pick one to work on. For example, I have this add footer to the index page. I'm going to have a look at a title and description to understand what it means. So basically, I got to add a footer to the index page. I think I can do this. So if you're working in a company, obviously, you can just assign yourself and start working on it right away. However, if you're working somebody else's project and you don't have permission to it, what you're going to do is you're going to say here in the comments, hey, I would like to help out with this issue, could you assign me? And then you're going to comment. And once you comment the other person, the maintainer, now let me assume the role of maintainer will look here and say, okay, I think this person can help. So I'm going to click here and choose their name. And it's important to comment first, because if you don't comment, I would like to help. The maintainer won't be able to see your name here. So the moment you comment, your name will automatically be available for assignment. So that's why you got to comment. And another reason is, what if you've got multiple people that want to help? And who are you going to assign to? So usually, you probably want to take the first come first serve basis, right? And on that same topic, I want to point out, make sure that you don't start on any work before you get assigned, because that might cause a lot of problems. For example, let's say I like this issue, but I never said I wanted to help out, and I immediately submit a code proposed, change this, but then I was never assigned to do it. How is the maintainer of the project going to know that you wanted to do it? And what if somebody else did the same at the same time, you're wasting a lot of effort, multiple people doing the same thing at the same time. So that's very confusing. And what do you want to do first before you work or anything? First, make sure your name is assigned to the task. So that's a very important thing. All right. So once you got your name assigned, and my name is here, you can start working on the feature. If you have like that kind of combo on board, you can click here on the projects, and you choose the board. I have many. So I think this one is the one I created just now. And if I do that, I can change my from to do here. And then other stuff that I don't really care about right now, but there's priority, size, and so on. And it can choose a state here. Let me keep it that way because I want to look at the board from a different perspective. So I'm going to click this project stab and go back to the board here. So I can show you that it's been added to the column here. And what I want to do is drag and drop to in progress because I've started working on this feature. Okay. And if I go back to that issue, make a note that's the issue number two. Okay. Every issue has a number. This one is number two. So right now it's in progress. You see here? Now, great. I got to take this source code. Usually you probably don't have it in your computer. So you got to clone it. Now, the problem is if I go here and click code, copy this SSH, and I'm going to do the git clone operations, basically downloading the code. You probably don't have permission to change this if you're working on an open source setting. If you're in a company, you will have permission. All you got to do is clone the original repository that is fine. And then you can push or send new changes to that without any extra permission. Now, if you're working in an open source setting, you don't have permission to that. So what you got to do is make your own copy of the source code. And that own copy is called a fork. Okay. So a fork is a feature from GitHub, not git. So keep that in mind. So what we got to do here, you notice this is my organization, MVK Tech World. And this is the owner of this repository called Full Stack Web Dev 3. Now, I got to create my own personal copy to work on that. Assuming I play the role of an anonymous person, right? Like some other random user on GitHub that wants to contribute to this project like you. So I would go here. Okay. I got to make my own copy. So I click fork. See that fork? Click that. And it's going to ask you, okay, where you want to fork? I want to fork to my personal account. This is my personal username. And I choose the same name so it doesn't create any confusion. And create fork. And GitHub behind the scenes will do many git operations to basically create a whole new repository and copy all the commits and all the history. And then it's going to place that under a new owner. If you notice at the top here, now the owner is my personal account, MVK Hope. Okay. With the same repository name. And if you notice this thing under the name here, it says forked from this MVK tech world such Full Stack Web Dev 3. And that means I have a copy of that original one. And if I want to go to the original one, I just click there. But you've got to be aware where you are. Whenever you're looking at GitHub, make sure you know where you are. Look at the owner and look at the repository name. Always. This is the original. If I want to go back to my copy, this is the one under my username. Okay. Once I got that, I can finally clone this, which is basically downloading the search code. And like I said in a previous lecture, you can do HTTP or SSH. SSH, I taught you how to do the SSH key so you can work that. So I'm going to copy that. So I'm going to go to a terminal. Let me share my terminal here. So I'm in a directory here. So basically I like to create my file system structure with this get directory slash my username. And this is to mimic the GitHub username structure. This is the GitHub owner. So that way I don't confuse with MVK tech. So I'm going to do get clone and copy the whole thing there, which is usually get at github.com colon your username slash name of the repository.git. And once I do that and IDIR or LS on Mac and Linux, I should be able to see into a full stack Web Dev 3 here. So I'm going to CD to that. I'm going to do CLS to clear the screen. And as you see now, I'm in the directory full stack Web Dev 3 under my directory MVK hope. And there's a reason I always do like this to mimic GitHub. So I don't confuse with the other one because I also have, I just happen to have the original. If I go to this other tab and the original is under MVK tech world. So I create a separate record for that. So I, even though they have the same repository name, it's a different top level directory there. So I don't confuse. Anyway, going back to my copy here, I'm going to open Visual Studio Code. And let me see. Share. Think this one, right? Okay. So here's my copy, my fork. And here are the files. So this right now is synced with the original. So I can start doing my work. So what I'm going to do is I'm going to press control tick, back tick to open a terminal here. And I'm going to first create a branch because like I told you in a previous lecture, right now we are in the default branch. We could be, could be master or main. And it's the main timeline of changes. But that timeline is supposed to be clean and free of problems and issues. If I start working on something right now, like I just a draft, and it's going to probably introduce a problem or bugs to the main timeline. So I want to branch off to a different branch that's called a feature branch and do my work there. That way the default branch is always, isolated from that. So get checkout dash B and then you name your branch. And yeah, I can use this at header to index page. I'm using the PowerShell. So it has this auto completion AI thing. Basically, I'm going to create a branch. And this is the name. Like I said, I use lowercase separated of a hash. And if I do get branch again, the star is now next to my new branch name. So I can, I am safe to do my work, make commit. And master or main branch will not be affected at all. Let me open CMD. So it's simpler. There's no auto completion. Okay. So I'm going to start doing my work after creating my feature branch off of master, the default branch. So I need to go locate. Remember the task is to add a header right to the index page. So I'm going to locate the file that I want to work on index.html under SRC. And I think locate the body. You recall everything that the user see is between the body. Open and closing tag. So at the beginning, I'm going to add a tag header, close the tag header. And this is where I'll add the site title. I don't have one. So I just write site title like that. And if you want to include that in the div or some generic thing you can do, but that's okay for now. What was it? Let me see if I'm doing the right task. Let me just check if it's not the footer. Hold on. Because that, that AI thing might have misled me. That's why I don't want to trust it. Let's go back and let me, let me always, we always have to check back on the task we're doing. Sometimes we forget. So go to the original issues. You can filter by yourself here. Assign, where is it? Assignee me. And it's footer, not header, right? So I just made a mistake. I was misled by the AI on creating the branch name. So actually footer, not header. Footer section to the bottom of the document. Okay. Now that I double check that, I'm going to go back and fix my problem. Let me see. It's supposed to be footer and it's at the bottom of the document. Site footer. Usually that is a copyright or a message, right? Copy rights, some year, site title or something like that. I'm going to move this cut that. Move it down before the end of the body. Put it here. And this, this ampersand copy semicolon is just an HTML, a kind of entity code that if you want to display the copyright sign, which is the C with a circle, you can do like this ampersand, the name of the symbol and semicolon to finish it off. I'll show you what it looks like in the preview. Control, shift, P, live preview, show preview, internal browser. And you see the copyright symbol there. It could be, it could make many symbols like GT is greater than. You can see greater than there. Lealt is less than and it appears there. Otherwise, how would you type the less than, right? Because it's interpreted as something special in HTML, like a tag when you're going to write the tag. So that's why you want to use that instead. Anyway, that's the entity. If you want to know more about that, it's called HTML entities. You can look that up. So I added that. We need to add some CSS to make it pretty. But before I do that, let's practice committing. And I'll do it the terminal way, like we've always done ever since the previous lecture. And I'll show you the graphical way through Visual Studio Code. So I'm going to do get status in the terminal. I see something's modified, right? So I'm going to do get diff to see what changed. And I can move with my arrows in the keyboard to see what changed because it's too small the window here. And if I want to quit that, it's Q, okay? So basically I have the header side type, which is wrong because I didn't save the file. Let me save the file and try again. Get diff. I saved the file now. I should be able to see footer there. There you go. Q to quit. So I'm going to get add index.html. Remember, always two step process first you add. And that's under SRC directors. I got to say SRC slash. And get status again. I've modified SRC index.html. It's now been added to the staging area. Change is to be committed. Now I can finally commit. So get commit dash m. So add footer to index page. You want to describe what you did. And that's nice. That's one commit right there. And if you want to do get log to see what you did, what's the history of this repository? You can see I just added that commit. Great. Now let's add some CSS here. I'm going to add a class called side footer. And this page, I think there's a link to index.css. But I know that for sure that I want to have this kind of footer in every single page. So I'm going to create a new CSS file that's going to be global to every single page. So that whenever I need that for any kind of page, I'm going to use that. So I'm going to create global.css. And I'm going to add the class.site footer. And let's add some padding 16 for now. Background color of let's say light gray. How about that? Just for starters, we can calibrate with the DAV tools later. And to link that file with the index page, we got to go and locate the head of the document. Remember, HTML document has two sections, right? As the head and the body. Let's go to the head right before the end. We want to add the link to rail attribute style sheet. And then HRAF is going to be global.css, the file name relative path. And that's a self closing tag. So you don't need to add a closing tag there. Okay, I would like to put that before my index in case I need to override anything. Great. Now, if I scroll down, you can see now the footer is kind of grayish with the some padding surrounding the content. So you can calibrate that to your hot content using the DAV tools and then copy it back to global.css. Okay, great. We did that work. Now how do we do commit? Well, follow the same process, get add, get commit. Now I'm going to show how to do that visually. If you go to the extension, to the source control section of yes code here in the sidebar, there's the icon of these circles. And this is basically, that icon is basically the main timeline and a branching off like I showed yesterday. So you're going to see basically the get status visually graphical. So you're going to see some things were changed here. If I click this one, I see I added the file global CSS. If I click the other one, I can see the get diff. I added this. All right, so what you're going to do is to get add, you're going to press the plus next to the file. So if I want to add index plus to stage the changes, if you want to get add global, you can also plus that to stage the changes. And if you notice, I can always get add multiple files. There's no harm in doing that. It doesn't have to be just one. So now that it's been staged, you can further confirm that that's really what you want. There's no errors. Okay, now when you're ready to commit, what you got to do is click here, this message text field and describe your change, style the footer for the index page. And then you click commit and that will call get commit. Okay, so this is the graphical way if you feel comfortable using that. But I have to teach you the original way, which is actually what's happening behind the scenes, right? This graphic is just a front for what's really going on with the get status, get add and get commit. Okay, I think my work is done. Now what do we do? Well, now that your work is done, you can send that to GitHub. So you can get push origin and name of your branch, which is wrong, right? It should be footer. But anyway, AI mislad me. And now it should be on GitHub. So basically, when I did the get clone to download the repository, it already automatically sets the remote called origin. So if I do get remote dash B, I have origin here set to that with the fetch and the push. What I did just now is get push to the origin remote my branch. So I push my branch. So if I go to GitHub, let's see here, Firefox, let me open a new window. So I go to GitHub.com slash my username slash full stack web that three, which is my fork. I should be able to see my branch. If I go to branches, let me look up here, right here, branches, click that. And this is like the graphical equivalent of get branch command. You see there's the branch here. If I click that, I can browse the files in the branch. And you see this branches to commits ahead of the original master branch. If I verify the files, I will see there's a global that CSS like we did add. Okay, that's great. So I sent to go to GitHub. How do you propose changes to the original? You see this yellow banner? That's pretty much the quickest way to do that. Click compare and pull request or the other more manual way can go to pull request and then start a new pull request and set up the different stuff. Anyway, click here. Let's verify this. So I usually read from right to left when I read this part here. So I want to do my branch add header to index page. That's that's from my owner, right, my repository copy. And I want to merge that into the master branch of NBK tech world slash full stack web dev, which is the original branch. Okay, so it has to be like that. Right, because you want to propose changes to the original. The original is NBK tech worlds one. So you want to give a title that's very descriptive and concise of what you did. So add a footer, not header to index page. And then you would go further adding more description about this. This one's very simple case, but usually you would say things like add some screenshots to be so people are it's basically want to make the other person who's going to review your code. You want to make their job as easy as possible and less painful. So the more descriptive and visual with screenshots and videos, the easier it will be for them. Otherwise, they got to take a long time to figure out what you did and all this stuff. So you want to say like describe what you did. If you had if you consider alternatives and that didn't work describe that add some screenshot videos and then describe what to do in case something goes wrong. You can say if this goes wrong, you got to just do this and that and that and all this stuff. Anyway, add a footer to the index page with some basic CSS styling. If you want to start discussion, you can also start here. For example, you're not sure about the color or something. You can say I'm not sure about this color and you can tag someone. What do you think about this color? Should I change something else? And you can start discussion just like social media and you can leverage the comments as we'll see in a bit. But basically do that create for request. And once you do that, you can start a conversation via comments here and you can tag people at sign and their name. I chose the light gray color for the background of the footer. Is that okay? Or you want a different color? So you can start a conversation there. And it's going to be here. The person will be tagged. Obviously I tagged myself, but I'm playing a role. If you go to this part of reviewers, usually that is usually automatically assigned depending on how you have everything set up. So somebody would be assigned to review your project here. Otherwise, you would have to go, for example, if you're in a company, you have to ask around maybe in the chat room. Hey, I just finished. Here's a poor request. Could anybody review it? And then we'll go there and start reviewing it. So you can verify the commits. This checks is basically the CITD. And then files change is everything you change. What's great about GitHub is you can look at the files change and it can actually comment on every line. And for example, why did I add global CSS? Maybe the person who's reviewing my code doesn't understand why. And I want to be preemptive and right here. I added this global style sheet because I think the footer will appear in every single page the same. So that avoids us having to copy and paste the same code for every single difference style sheet file specific to a page. Something like that. And then add single comment. That way the person who is going to review the code will be aware of what you did, what you were thinking. Okay, so once you do that, there'll be somebody like a reviewer. Let me play the role of reviewer. So I would come here. Okay, I read the title. Okay, add footer to index page. Add footer to index page. This one is very simple. There's this one detail here that I didn't mention. In the real world in practice, there will be many issues. And you cannot possibly keep track of them all. You have no idea what's going on. If you just put out some poor request out of nowhere without tying that to a specific issue. So what you got to do is specify the number of the issue here in the description. For example, resolve number, whatever. So you have to add that. So that as a reviewer, that's the same. The first thing I noticed here. And then okay, add footer to the index page. Sounds good. And I would look at the files. Okay. This has been verified. Good. Somebody commented, oh, why did they do this? Oh, okay, it makes sense. Okay, it makes sense to me. So we can move on from there. Okay, looks great. And then it can leave comments if you want. So I finished my review and I say, okay, everything looks good. But could you link the issue number? So I know exactly what you are solving or addressing. So I would do that. And then playing the role of the person who proposed the changes. I would say, read a comment. Okay, makes sense. So I'll go here and edit my thing. And usually at the beginning of the description, I would say resolve space hash. And which is the issue number two, right? And when I click update, it should be linking that to this pull request. If you hover over that, you can understand, oh, this is resolving that specific issue. And then here in the sidebar, it's also linking to a pull request. If you click the issue, it will know, okay, on the right hand side, that's successfully merging a pull request may close this issue. And if you go there, that's the associated pull request. So that way they're linked together. And the benefit of this resolve thing is also when you finish the issue and click close, it will automatically move. For example, in the board, it will move from in progress to done without you having to manually do it. Okay, so once everything is ready, so we got to do what's called the merge operation, which is basically integrating the changes into the repository. Now that will vary depending on how we are working. It could be the person who proposed the changes to merge, or it could be the maintainer or the project that will merge. If you're working in a company, you could merge yourself. If you're working on somebody else's, you have to wait for them to do it for you because you don't have permission. But yeah, typically there could be some process there to deploy first to verify there's no problems before you merge. So you have to be aware of that. Depends on how the company approaches the stuff. For example, for me, in my case, when I work in a previous company, we would first deploy this feature branch to validate if it's actually working and there's no problems. And once we verify there's no issues, is when we would actually click to merge. Okay, other companies might do the opposite. They might merge right away and then they will verify and if there's issues, they will backtrack, which I don't really recommend, but that's just the way people choose to do things. Anyway, I think this is all good. Let's assume I deployed and everything was great. And I am the maintainer, so I have to merge here, click merge, confirm. So now these commits have been integrated into the original, which is this one. So I can click commits here and I see my two commits here. Add footer and style the footer. Okay, that's great, but now we have to clean up. So you notice here, I have my branch. So usually you want to delete that because I don't need it anymore. So I can delete from here. And I have to go to my local and start to clean up process and synchronization, because if you go back to the fork, my fork, let me go to my fork here, getup.com, slash MBK hope slash full stack, web.3, this is my fork. You see this branch is behind. So we are out of sync now. So let's clean up. So go local. So VS code here in the terminal. What we got to do here is first, let me go here. So if you look right now, we'd have no way of synchronizing with the remote from the original. So we have to add that. And that's usually called the original. So let's take one step at a time. First, I need to get the changes that were integrated into the original. Now, keep in mind, what I'm doing right now, there could be different ways to go about doing this. Obviously, you can merge it because you did the branch here. You can merge that into your master and then sync. That's fine too. But let me do it, a syncing from the original. So what I'm going to do here is I'm going to go to my So what you're going to do is get a remote add. And we call it upstream instead of origin. And then you've got to copy the URL from the original. So let's go to GitHub here. So from your fork, you can click to go to the original. There you click to copy the URL. I'll do SSH. And going back to my terminal, I paste that. Make sure it's the original. Okay, I look at MBK Tech World. That's not my copy. It's the original one. Enter. If I do get remote dash V, I should see two for upstream. Now, what I'm going to do is going to fetch the changes from upstream. So I'm going to get fetch from upstream master branch. Now I got those changes. Now I've got to update my master. So I'm going to locally get checkout to master. Because right now I'm not in master. If you recall, if I scroll up, right now I'm in my feature branch. So I've got to go back to my master, right? I'm here. Now I'm going to sync my master with the original master. That's in the upstream remote. So I'm going to do get merge upstream slash master. Okay, so that's going to take the master branch from upstream, which is the original one, merge those changes, all those new commits, into my local master. Okay, now if I do get log, I'm going to get log. Okay, now if I do get log, I have those commits, right? This is what we did, style the footer, add footer, kill to quit. Now this is all great, but it's not yet on GitHub. It's only in my local machine. If I go to GitHub, go back to my feature, to my copy, my fork. This is my fork. I still don't get the commits. If I click commits here, I don't get them. Why? Because we've got to push, right? We've got to push to origin. So I go back to VS code. Going to do get push origin master. And that will send synchronize, right? Everything that I have locally master, we'll now go to GitHub in my fork, my copy. Now, going back to GitHub, refresh, I can see my branch is up to date. And if I click commits, I will see them here now. So now we updated our fork on GitHub, with our commits. And then it's, that is now in sync with the original one, okay? So you always want to make sure, before you do any work, that you synchronize everything, otherwise you're going to be behind, right? Because there's always people working on the original, and adding new features. So that's why every time you're going to, about to do any new work, always make sure to fetch and merge, which is what's called pull. If you want to combine two, it's called the pull, get pull. Before you do any work, otherwise be working on old stuff. If you have a question, let me know. Let's simulate somebody changing the original, and you don't have those changes. Let's go to the original here. This is my original repository. This is my original repository, and I have the permission to do it. So I'll use the git web interface to change something. For example, I'm going to go into source, I'm going to go, let me see here. Now, before I do that, let's clean up the issues, right? Something I'll often forget. So if you notice going to the backlog, and I refresh, it's being automatically moved to done. So that's why we always have that resolve hash in the description of the pull request. So it does this for us, otherwise we have to move it manually there. And you would have to click the issue, and click to close it here. But because we had a resolve, it automatically does that for us. You can see here, the pull request was merged. The moment that happened, the issue is automatically closed, and then automatically moved from in progress to done. Because of automation, we often forget that's even a thing, right? Anyway, let's move on. I was saying, I wanted to simulate a change for somebody else. So let's say somebody else changed the file index, and I'll click to edit here on GitHub. And let's say the added a paragraph here. Hello, world. And I'm going to commit. Now, I'm going to do directly to master, just to simulate it. But usually we currently want to create a branch, feature branch, okay? Now, I made a commit here. And this commit is only in the original. But we don't have an order copy. If I go back to my copy, let me see, this one. I look at the commits, it's not there. And you can see this branch is one commit behind. That means somebody else made a change to the original. And now we're out of sync. So how do we sync that? Well, you can click this to sync. That's one way. Let me teach you how to do it manually through the command line. So in the local, every time you're going to start new work, right? And by the way, I should make sure to delete the local branch here with git branch dash D because no longer needed. So git branch dash D. Add header to index. So it's gone to clean up locally as well. Okay, now we're here. We're going to do with following when I want to make sure there's no new changes from upstream. So I'm going to fetch upstream master. And I see there are some changes. So make sure you're a master. So I'm going to do git merge upstream slash master. Now I got the new change. Not going to change. Now I got the new change. Now I can start working on something new. And to update my GitHub copy, you got to do git push origin master. Okay, so if you're doing open source, it's a bit tedious because of this back and forth between your copy and the original copy original. If you're working a company, you don't have to do that. It's always directly changing your repository, the original always. So that's why it's a bit more complicated. But let's see here. Just to try to make a picture of that. So let's say we have the original one. And that's the master branch. So we have a timeline. The repository is the original timeline. And then we got ours. Our copy or fork. Master. This is basically our repository fork. So in a branch timeline, we have commits. So we would have a commit here, another one, another one, and so on and so on. So mine is also in sync right now. What I just did, what happened was somebody else came along and added a commit to the master from the original. But I don't have that. So what I want to do is bring that to mine. That's why I have to sync it. So, but to do that, you got to do, you got to first do the, oops, the operations, right? You first got, okay, you got to fetch all of these into my local. Once I got that, I can integrate with the merge. So I have it here. However, I need to send it to GitHub. That's why I got to push that push to GitHub, right? And if you don't, you don't remember, you don't know what the heck is going on. Just copy the commands down. Let me put in the zoom chat. Basically get fetch upstream master, get merge upstream slash master. Make sure you first get checkout master. Let me see. And then get push origin master. Those are the four commands you run to sync with the original and then push back to GitHub, your copy. Always like that. If you follow the pattern that we did, let's see. Yeah, so let's do another one just so I can review with you. So, and by the way, you can, I made some issues here to the repository and you can actually go there and ask to do it for practice. I made it for you. So if you're interested in doing that after lecture, that's the link. You can go there and pick one of them. If there's none of them anymore, I create one for you. But basically you go there. Let's do a easy one. This one, wrap the main content for the next page. Remember, first comment. Hey, let me help you with this. And then as the maintainer will look at that, okay, you're being assigned to that. Now you can start working, but don't do before you do work. You get assigned. Okay, I'm assigned. Let me look at the board. I'm going to add to the board and we're going to put in progress. I already have the code, right? I cloned it, my copy, my fork, right? I went to code, I click fork. So I got my fork here, and I have everything. So I clone it going here. So I have it in my local machine. After doing that, I go to my local here. Let me make sure I'm in the right place. I mean, the master branch, first, I want to make sure I'm in master. I want to make sure I'm in sync with the original before I do any work. So get fetch from the upstream master, and then I'm going to merge from the upstream slash master. Be careful of that slash, okay? And the reason for this is this is the name of a branch as one thing. And this one is our as the name of the remote and the branch name. And then we're going to do, okay, we're going to do, okay, locally we are in sync. We can start, get check out a new feature branch. And let me, this one is for, let me look at the issue again before I forget. I don't want AI to mislead me again. That's for the main, wrap the main content of index, okay? Index main content. We are now in a new feature branch. I can start doing my commits, my work. So I'm going to do to index. And I think I want to move all this stuff to inside a main tag. So I'm going to go here at a main. This is just a semantic tag that it's meant for the main content of things. But in truth, HTML can use dips or everything, but they try to be semantic these days. So the computer can better understand the web pages content. So add the closing tag there. So everything is now between the open main and the closing main. So that's the problem we're solving right now to better organize our page. Great. Now let's do the commit. I'll do it graphically again. So you understand how to do it. VS code, you can go here, I can verify, okay, I change add in main. Everything's been moved inside. I'm going to click plus to get add. I'm going to verify again, all good. And I'm going to write my commit message in close main content of index page in main tag. Click commit. Great. I might have noticed VS code has this publish branch feature that you can use to actually run the get push for you. But be careful. I don't know which remote is going to go. We want to do origin first, because origin is our copy. So let me try. Let me just try. What is it going to do? Oh, it's going to ask which one you want to do. Okay. So I want to get push to origin. So I'm going to take origin. So it just did the get push origin index main content, the name of the branch. Now let's look at GitHub. And you can go to your copy and look at the branches to see that it's there just to verify. And you're also going to see this yellow banner. Let me try to show you how to do it manually through pull request. Let's see if you click new pull request here. You can try from the right to left. I want my feature branch. From my copy. That's correct. And into master. Yeah. All of the original. Yes. And you can verify your changes here. Looks good. Create pull request. Let's describe the title and close main content, index page, main tag. That looks good. Let me say in the description resolve hash number eight, right? That's the name. In practice, it's going to be thousands, if not hundreds of thousands of issues. So you might want to reference, go back to that issue page and copy the number because you might not know right away. Okay. I think I'll use this one. And then I enclosed the main content of the index page inside a main tag. As, as I understand the footer should not be part of the main content. So I left that out side and then I would put some screenshots here maybe, but it's visually is not the, it's the same thing. So it's kind of not, not so useful, right? But anyway, I think that looks great. I think that looks great. In case anything goes wrong, just roll back the commit, go pretty much go back in time to get history and deploy that again. Create pull request. And then if you're working in a company, you're asked in a chat or, hey, could you review my pull request? Here's the link. If you're in the open source setting, they'll get a notification saying a new pull request was created and then the maintainer would go and somebody would be assigned to review may probably themselves. And then they would look at here from the point of view of the reviewer. There was read descriptions. Okay. This is the issue. Maybe they're confused. They're going to look at the issue. Oh, okay. Makes sense. And look at the files changed. Good. And if they have any questions, they would comment here. Otherwise, they just approve. Click review changes, approve. Okay. That's what we typically do. We'd go review changes, mark approve, submit review, or otherwise you would have to comment and ask them to change something. Now, GitHub doesn't let you approve your own thing. That's why it doesn't let me. So usually when we do code reviews, you always ask somebody else to do it, not yourself. Of course, you can break the rules. If you're working a startup, which is fast-paced, you can break the rules. But typically in a big company, you have to have somebody else review for you. Okay. It looks good. Let's say the person a review and approved. And then again, it would deploy and then verify everything is okay. No issues. And then I am the maintainer. I will merge. And then you can start cleaning up again, delete the branch. And then we're going to go to our local and sync. We are here. Let's go get checkout master. Let's pull from the original. So let me teach you pull, actually. Somebody might be asked, what is get pull? That's the combination of fetch and push. So I can do that get pull from upstream master. That's going to do the fetch and the merge. Sorry. I didn't mean to push. It's fetch and merge. Okay. Not push. Sorry. So that we did fetch and merge at the same time. Now with that, I can finally push to my origin master so that my copy is updated on GitHub. And then finally I can clean up my issue. Oops. Let me first delete my branch here because I think I have a branch. Branch dash D to delete index main content. Oops. There you go. Get branch again. Looks good. Let's go to GitHub. Clean up the issues. It's automatically done for us due to automation, but you just want to double check. Okay. Go to the issue and make sure it's closed. Okay. Otherwise you got to go to the bottom and click here and close. Let me show you. If it were not closed, you have to click close here. And then you have to go to the board, which is a separate thing. And we'd have to move from in progress to done. Like that. Due to automation, this automation happens because of the resolve that we put into the description. So that's why you should always do that. And it will move everything to done for us. And that's it. So you can just keep doing this. Of course this process is more involved for open source, but if you're working in a company, it'll be a lot easier because you don't have to do your fork and you don't have to be syncing all the time. But you still do have to sync with the latest commits because there will be people adding new features all the time to the code base. So you still got to fetch and merge or get the latest changes from the master branch. Okay. And with that, I end this lecture.