Okay, today I'll talk about collaboration on GitHub. For that, you need Git installed in your machine. You need the terminal to run commands. You need any text editor like Visual Studio Code. Any GitHub account, like I said, and login. So, in the previous session, I thought about Git and getting started on GitHub. This one is more focused on GitHub and collaborating on other people's projects. And even if you're working on a team in some company, how would you go about taking on work to do? So, we talk about issues. We talk about colony repository. And then we will do some collaboration by opening pull requests. All right. So, I'll be using this repository here. And I'll paste the link in the Zoom chat. So, imagine you're on GitHub. So, GitHub is a place where people can host their source code. It's really popular for what's called open source, where people can post their code to the public. And then other people can look at it, and if they like, they can propose changes, or maybe they can just post issues or problems that they found as a software, in hope that the developer or maintainer of the project will look at it and fix it. Or maybe it's a new feature request, and they can work on that as well. It's really popularized, you know, social coding. It's like social media, but for developers, people who build software. Of course, there are other services similar to GitHub, but by far, I think GitHub is the most popular. Other services, maybe GitLab, Atlasian Bitbucket with cheer, Microsoft, Azure DevOps, and so on. So, if you use any of those, it's the same thing. So, there are different ways you can go about GitHub. You know, if you're working on a company on a kind of closed-source repository, your post-source would be private, and you'd be given tasks to do. And then you take on those tasks and work with the closed source from your company only. But if you're out there in one adventure to open source and helping other people's projects, you can go here on GitHub, for example, github.com slash explore. That's also available through the menu. And you can explore other people's code if you're interested in helping them out. You can make a search at the top if it's little subfilters. And here are some trending repositories, developers, you know, who are really contributing to open source and so on. So, as an example, let's click on this one. So, you can see this is the code for this project. And what you want to focus on is we have what's called the issues tab. So, when you click there, it's like these are problems or maybe feature requests. So, whatever people find, they post it here. And it's up to the maintainer to take that feedback or not. And pull request is basically a proposal of changes to this code base. So, you have the code here under the code tab. Let's say you look at the code and you see something funny. For example, I click this code and I look, oh, I think this is wrong or maybe this could be better. You can always click to edit on the spot using this icon here and then go about the flow and everything. And ultimately, it will become what's called a pull request, which is just a proposal to change the code. And you can see, as an example, the person has a title and a description of what this change is about. There's even screenshots to make it easier for the reviewer to see. And you click files change to see what they changed. In my view, I have before and after side by side. On the left is before and on the right is after what they changed. You can also change this if you click the gear with a unified view and apply reload. And this would be like altogether. Anyway, I like seeing them split. So, I'm going to choose split here. That came later now. We're just looking at github.com right now. Just looking at examples. Let me go back here. We're just browsing github.com slash explore to see if there are some interesting projects to contribute on. As an example, I post a link to the Zoom chat. And you can just browse it and see. And I talked about issues, which are like things to do or problems in the code or feature request. And then per request, which are code changes, proposals. And these are the most basic things that we will talk about today. Yes, you need to sign into github. Anyway, I'm going to go back here to my repository. If you want to go there, I'll post a link again. And we're going to work on this project. It's like a very basic... There's nothing much going on here just for demonstration purposes for this class. This was made in the previous lecture where we worked with git commands. Obviously, I have one file here called test.txt, which just has a message. Hello there, let's try SSH. In a real world setting, it'll be a source code, most likely. Going back to the main. So let's assume we're working on this project, on this repository, or we want to contribute to it. Remember, we can either be working on a company in a specific team with closed source, but that still uses github in private setting. Or we can be out in the open for the open source and collaborate with anybody else's repository. So let's say I'm here, okay, I want to help this project. Maybe I found something in the text file that I don't like. I found some problem with the software. Or maybe I just want to help out, so I want to find out what their issues are. Should I click issues? And I can see there's a lot... There's not much going on here, but for the sake of example, I can see this one, for example. And this issue, they have the title, they have the description of what needs to be done. So typically you would read the title to understand what's going on in the description. And if you think you can do this, you can always get assigned to do this work. Before we do that, let's go back. You can notice here the list of issues. The first one, I am the assignee. So I am taking on this issue. So you can see assignees on the right-hand side. That's me. For the person who just got here, we're talking about GitHub. And we are looking at this repository as an example for the demonstration today. And I'm pasting the link in the Zoom chat. Again, we're acting as though either we're a member of a team in some company in a private setting, or we're just out in the open, trying to become an open source contributor to somebody else's project. So in this case, this issue is assigned to me, meaning I am working on it. And there's another view that I'm going to show you, but we'll talk about that later, which is like the board view. So this is like a board view of those issues. And you can access them if you click Projects under the repository. You click Projects, and you click this one that I have. I think I made it public so you can see it. In any case, in this other tab, this is what happens. Typically, this is for teams or you to manage your project. So we have the column for to-dos, things that you have to do, and things that are in progress, and things that are done. So as you can see, I am doing right now a task or issue. That's to teach a lecture about Collaborator and GitHub, what I'm doing right now. So I put that in progress. Now, what I've already done is teach about Git. So I did that on a previous section. So therefore, it's in the Done column. So this is like project management, you know, going about what you need to do, what are your tasks, and so on. Now, going back to that issue, going back to the list of issues. I want to practice with you this one. Let's say you look at this issue, you think you can do it, or maybe your manager wants to assign you to this. So if it's your manager or your manager tells you you could work on this, or you can just pick it up from your team's backlog of tasks, you would go here and click this engine icon, and click or type your name, like it would appear here. And it can click on yourself or somebody else. If you're a manager, maybe you would assign somebody else here. Now, because you don't have ownership of this, if it's typically when you don't have ownership, you would have to go here and comment out saying, hey, I want to help out. Can you assign me to this issue? And just comment there. And then the maintainer of the project would go here and click the gear and type the person's name, and click here to select them and click outside. And then they would be assigned, meaning they are the ones that are working on this right now. Now, if you want practice with me, just go there. I post a link to Zoom and post a comment asking if you want to be assigned to the issue. I want to help out or something. Then I will assign you here to simulate a real world setting. All right, thank you for posting. So when you comment here, I see, okay, you want to help out? Yes, so I'm going to go here. So I would write your name and the CLLC and click there. And then now you're assigned to it. Imagine I'm doing just a demo right now, but you would probably just have one person assigned to one issue, not multiple, okay? So because I'm doing with you, I'm going to have multiple signings, but probably in the real world, there'll be just one and only one person working on it. Otherwise, it'd be kind of a waste of time to have two people working on the same thing. All right, thank you. I'll assign you as well so you can do this issue. Imagine it's just you doing it. All right, that's everybody. Now, once you got this assigned, you can always, if you want to go to the board, your team might have something similar to this. And sometimes it's not even on GitHub itself. It could be on an external service like Jira from Atlassian. So keep that in mind as well. It doesn't necessarily have to be everything on GitHub. So you can see it's not on the board yet because we got to add. So typically what you would do is, you know, is your page under projects in the sidebar. You click the gear and you select the board you want to place this in. This is the one I was looking at just now. And then you can see status here, no status. And we're going to look at the board before we set that. And you see a column, no status appeared. This is not usually good. So you want to have this in the to do at first. So either you can go to the board view here, which is typically if for those who came later, the board view can be accessed if you click projects tab under the repository and then you choose the project. And this is the one that I have. So you could drag and drop click and hold and then release the mouse here like this to to do, or you could directly from the issue. You could click the status here and choose to do. That way, if I go back to the board, I will see now that it's under to do meaning I'm about to do this. Somebody is assigned to do this issue. Now, once you you're ready to start working on this, you can always move it to in progress, like drag and drop, for example. Now, people on your team, your manager, or whoever is in charge of this repository will see that you're working. Who is working on what issue in the real world center be a lot of items here in the to do in the in progress and in done. Anybody have any questions so far? Oh, good. Okay. Yeah, so now that's in progress, we can start doing stuff about that. So here's the task we want to add it to file tax dot test test dot txt and just add sent to say what you're studying if you want to add your handle there. You're free to leave that as well. So as a person working on this, I would go to code. And then I first have to clone this repository. Now, there's two ways. Like I said, if you're working on a private setting in a company, you likely have permission to work directly on this repository, in which case you would click closed. And then you click to copy the URL here. In this case, I can use SSH because they set it up. So if you don't have SSH, choose the HTTP. In any case, I'm going to choose SSH. And then I can go in the terminal. Here in the terminal window in a directory where I'll start my projects. Typically, I like to call the namespace with the whatever, you know, in the browser, if you saw GitHub, it said NBK tech world slash introduction to get. So NBK tech world is the owner of this repository. So I was like to name space my directory structure with that owner. So I know that this repository that I'm about to clone belongs to this owner. Now that I'm ready to copy that code or clone it, I would do get space clone space, base that link. Like this in a press enter. Now you probably won't be able to do it because you don't have permission for this. But if you were in a team in a private setting, you'd likely would be able to do so. And I already have that. So I'm not going to press it. If I do dear, I can see it. It's already here. And if I see the introduction to get to change directory, I can see all those files are there with the test.txt. Basically, I took whatever was going on GitHub, and I kind of downloaded it into my machine using the get clone command. Okay. Now I'm going to see back to where I was before. Now I'm going to demonstrate the other one because what if I don't have permission, right? That would be you're working on somebody else's thing. Yes, somebody asked clone is not a fork, right? Yeah, so we're going to do the fork now. The first case is when you don't have permission to work on the original repository. So if you're working in the open source setting where you want to contribute somebody else's project that you don't have permission or access to change the code. That's when you would create your own copy called the fork. That's not the original, but under your own name space. So let's go back to GitHub. And see, let's see, I like this repository. I want to contribute to that, but I don't have permission. So what I would do is I would click this icon called fork here. Fork your own copy of this repository. So I click that. And it's going to ask me some information. I'm just going to leave the default. Okay. And if you want to change it, feel free to do so. But I'll leave it. You see it's now under my name. So to differentiate, imagine that TMBK tech world is somebody else. And I'm putting under my name, even though I own this organization, but I'm still cloning somebody else's fork in somebody else's work. I click create fork. What's going to do is it makes a copy of that repository, but it creates a whole new repository that kind of points to the original. Yeah, you asked about clone. Technically, it's like a clone operation in the sense that it copies the code. But the fork operation itself is just GitHub's thing is not from Git itself. If you want to do this manually as possible, it will be basically you clone the repository, then you change the remote so that it points to your version. And you connect with the original one via another remote entry. Git remote, I'm talking about. That's a command to change, you know, the remote location. In any case, after you click fork, you're going to see here introduction to get forked from the original. So you have a link to the original that you can go there. But you have your own version here that you can always change. So what we do now is we clone our own version or own copy that we have access to. So click code and copy the link. I do SSH because I already have it set it up. Then I go to the terminal. And let me see the back to one level up. And I usually like to have the namespaces for who wants what so make sure to mkdir whatever the user. This case will be my username. So if you're typing type your username here to create a directory to namespace. And then you see D to that and finally can get clone that. And now you're calling your own copy. And if I do a dir or LS if you're a macro Linux, you can see it's here. I can see D to that. And if you notice my path, it's always the owner slash whatever. That's very convenient. That's why I tell you, I suggest you to make a directory with the owner there. So I'm talking about the introduction to get my version. It's not and the KTAC worlds version. Even though I could technically clone and the KTAC worlds one, if even if I don't have permission, I still cannot propose changes or change the code in the original. So I want to differentiate them by changing my owner namespace directory here. In any case, let's see we have this. I'm going to open a visual studio code with the command code space dot. And I have it here. So the in the real world to be many files, you have to figure out where to change what. So you have to study the code and everything. And here it's very straightforward. This is the file. I'm just going to add an entry here saying. Hello. I'm my handle. I'm studying get up. So you just do that out of message there. Save that. And then we're going back to the terminal. I'm going to get space status to see if anything changed. So it's saying that I modified tasks.txt. So we're going to go through the get flow right to make a commit. First, you got to assist us to step process first you come you add and then you commit. So get add whatever file we want to stage. Now do get status again. Now we know now it's green meaning changes to be committed or staged. This file has been staged. And now it's ready to be committed. So what do we do is get space commit command. Now if you add a message dash M. And you're going to say we're going to describe your change. Let's say add what I'm studying. Something very descriptive. And enter. Now, if you do get space log that will show you a history of changes. So you can see the latest change is by the author me here, the date and the description of what was changed. And this commit capture that change that I just made in Visual Studio Code of adding that line of text saying my handle and what I'm studying. All right. Now keep in mind I did everything in the master branch, which is the main one. It's either master or main depending on your version of get and how you built with GitHub. They renamed everything to main at some point, but this is the default branch. Are you going to see a star next to it. So whatever is to the right hand side of the star is the name of your default branch could be main or master in the old times. Okay. Typically, I want to already typically we don't commit our changes to the main branch because that's supposed to be the stable version. When we want to work on something new or add changes to the code, we would branch off and create a different branch called the feature branch. And we do everything there and then what's already we propose a change to merge into the master one. We can do that later but for now let's keep it simple and just have master like that. So once you have that there, I can push my changes to GitHub that is kind of like uploaded with get push dash you origin master. Now that she was the option to track that branch. So I always leave it put it there just in case. Origin is the name of the remote. In my case, this would point to that GitHub repository my copy and then master is the name of the branch. Okay, now that we do that. Before that somebody had a question. Do you rename the new branch or keep the same name. I didn't rename any branch. Okay, I use just the default branch. I didn't I haven't created any other branch. So we're just working off the main or master whatever whichever you have there. Okay, after pushing that. Again, if you refresh your page on GitHub, make sure you're on your fork page, not the original one. Now if you see your page you're going to see this branches one commit ahead of the original, meaning you added one commit or change that the original does not have. Now if you're satisfied with this change, what are you going to do is you're going to propose changes to the original. And there's already convenient button here to, you know, contribute or sync for it. But if you want to do it the man away without relying on those buttons just so you know, to propose any changes, you just go to pull requests and click to create a new pull request. And then you got to tell Kate. Let's read it from the right to the left. Okay, so we're going to read head repository. This is ours. And we're doing the master branch and we want to propose these whatever master branch we have right. It has some new changes and we want to sync that with the original, meaning we want to merge our master branch from our copy into the master branch on the left. Here of the original. Okay, read it from the right to the left. Merge ours on the right to the original on the left. Since we're only working off the master, you don't have to change the branch. Okay, and it's already selected to me the original here. So you can see the list of changes here. I can see we added a new thing. And you can click create pull request. And now it's going to ask what's the title for this change proposal. You can say specifically add a sentence saying what at mbk hope is studying this case maybe be more specific. Saying that, you know, always be very descriptive and to the point, you know, so the person who is reading this later will understand right away what you're talking about. Let's add a sentence saying that mbk hope is studying GitHub. This is very specific. It's very clear. And then the description here of what you did typically would be, okay, what did you do in a nutshell. Is there anything that you want the person is going to look at the code and review it to know something that's not obvious. Maybe you want to leave a screenshot. If you have a picture screenshot, you can drag and drop here into this box and it will upload for you. And you want to add maybe something what to do in case something goes wrong, right? Is there a reversal? How can we revert this? It maybe this is under what's called a feature flag. And if anything goes wrong, you just turn off the flag. It's like a switch on and off the feature turns off and we have no more problems stuff like that. Okay, so I'm just it's very simple right now to have much to say. I went and added to the file. That's the XT and added a sentence with my handle and the topic I am studying get up to revert this change. I don't know you can either gets call the command get revert with the commit shot or just remove the sentence altogether, something like that. And so on and on and on. Right now we don't have much to say. So typically, we would have people review this. If you know that somebody in your team, or the maintainer, you can click here and add the person to review. Otherwise, you can keep empty and eventually somebody might come to it and take a look and review assign themselves to reviewers and have a look. I can add other stuff like labels. You know, it's a bug documentation, whatever this is depending on how the project works, whatever labels they use. And like I said, you can also add to the project as well. Let's try doing that. And other stuff that we don't really care about right now. So click create for request. And you're going to see this here. And then files change tab and so on. So typically, what would happen is the person in charge of this project or the team would get a notification saying, hey, somebody proposed you changes to the code base. And the person would go there and click this and come here and review this. You know, okay, let me say I'm a reviewer. I like this. I'm going to assign myself here. I can't do it myself, it seems, but I would take a look at your description, your title to understand what's going on right away. Okay, you're adding sentence saying my hand was starting to get up. Now I look at the code changes. If I click files change, I see, okay, before and after. If you have any problem with this, people would typically comment on it. And to do that, you see this line has a plus. So you're going to go here. Let's say I don't like this that they're together. So I'm going to go here and say as a reviewer, imagine I'm another person that's reviewing this typically want to have somebody else review your code just to be safe. You know, because if you wrote this whole thing, it's best that somebody else review it because you might not have the same ideas and they might find something that you didn't find. Okay. So I'm going to go here as a reviewer, let's say, could you add a blank line between these sentences. This is my comment, I click click to start review, and it will save all these comments for later where I can publish them when I'm done, or I can just add the comment right now. So if I do start a review, a review be started, and you can start commenting on everything you want. Once you're done, you're going to finish your review here. And you're going to either, you're going to say key I left, I left some comments for you to address or something like that. And then submit my review. This code has been reviewed, and I left some comments. Okay. Now you as the person would get a notification usually saying hey somebody commented, and you're going to come back here and address every comment that they have. You can come here could you add a blank line you can either disagree or agree. Okay. And if you disagree, give you a reason why explain your thoughts. I tried doing that, but it didn't work. That's why I had it written this way, something like that. And then you can start a conversation here. It's like collaboration. One person goes says one thing you reply with another they say something back and then eventually come out of a compromise out of this. Okay. Let's say this is good for me. So I'm going to say sounds good. And what I'm going to do is make the change not to make the change I go back to my vs code. I'm here. I'm going to add a new line be separating what I wrote and all the other stuff because that's what the comment asked for. Once I'm done with that, I got to follow the same process in the terminal. Okay. Get status to check what's been changed. And I know it's test.txt. And then get add tax.txt. And then finally get commit dash m with the message. Okay. We can do that same thing again. But I want to introduce you to another way of using get. And that's through the graphical user interface of visual studio code. If you use some other text editor, it probably has the same functionality somewhere there. So in visual studio code, it's on the left hand side. There's this version control source control icon. You can click that. And this is like the get status graphically. You're going to see there's some changes. If you click that, obviously you added the green thing. It's a new line. So this looks good. So I'm going to add this to get at this. You click the plus to stage the changes. Once I click that, you see it went from the changes to stage changes section. If I click that, I can confirm once again, this is what I want. That's fine. Now I can finally do a get commit by typing the message here. Okay. Add blank line before sentence. And when I want to confirm that, I click commit button. And that's done. If I look at the get log in my terminal, I'm going to see that commit just appear here at the top. Add blank line before sentence. Okay. So that was all done graphically through the interface of visual studio code. So it's up to you to choose which one you like better. I use both. And if you're starting out, try to do the commands manually in the command line or terminal until you get comfortable with that. Then you can proceed and do everything graphically because you already understand what's going on behind the scenes. Any questions so far? All right. So great. Now what we have to do is we only change the code added in your commit locally. You have to send that to get hub. And you can just do get push. The same thing again, pretty much that you are the master. If you had already pushed before a branch, you probably can drop the dash you are the master with just say get push. And it will work the same way. Okay. Now the changes are on get hub as well. You go new share. Let me go to the page there. Now I'm back to get hub. I'm going to scroll up and click files changed. Did you notice now I have a new line here line three. So everything changed accordingly. You don't have to do anything at all. As long as you push the branch, get hubs, pull requests will automatically show you the change. You can see in the commits tab that it also has that commit with the add blank line. And I click click that to see the details of what I just did. You can see there's a blank line there. Okay. So going back to files change. Once you're done with that, okay, this topic here is kind of done, right? You don't have to talk about it anymore. You can click to resolve the conversation. So it goes away. So click that and it's gone. It's, it's hidden, right? If you want to show it again, click show resolved, but case is closed. You don't have to dwell in it anymore. Okay. Now this is all good. What happens is once you're ready for review again, you know, I didn't say anything about the board that typically going back here to the board. You can see the, I didn't choose the status for that poor request, but you can see, you can also have the poor request on the board. So you can move it around. It's in progress. But typically teams could also have another column here called reviewed or in review. So he could probably move that one to in review, meaning it's in the review process. Somebody is looking at it. You have already finished most of the work. You don't have anything in progress. It's just waiting on review. So that's one thing to keep in mind. I don't have any column for you right now, but you could also add if you click here, a new column. In any case, so the reviewer would go back here and look at your code. See your change. Okay. Thank you for commenting here. Any case. So the reviewer go back. Okay. You added the line. That sounds good. I approve this. So the person would go and click review changes and they would click to approve here. Now this one isn't working because pull request office can't approve their own that if it's somebody else's, I would click approve and then submit the review. And then the code is approved, meaning it's ready to be launched. So depending on the company or how the project is maintained, they have their own process of taking these changes and deploying them. Once it's approved, the person would go here and they would say click merge for request, which means these changes will now be integrated into that project. So I click merge. Depending on the company, it's either the maintainer or yourself. If you're working on a company, you could merge it yourself if it's allowed by the policy, otherwise the person who is the maintainer would do it in the open source setting. Okay. This has been merged. You can see that there. Now if you go to the code, notice we are in the original. Okay. Don't confuse. Look at the namespace here. This is NVK tech world. That's the original. You can see if I go to test.txt that my sentence is now here. Okay. So that's how we work. Now I want to be careful. Later we have to clean up our local. If we have a feature branch usually. And then sync with the original. But let's go back to progress here. I want to see yours. So okay. I want to see you do it and in this project and send me your change. So it looks like we already have one. Thank you for doing that. So I'm, I am the reviewer. I would go here. A screenshot and I said, okay, cool. If you have any more comments there. Yeah, you can also do this. Oh, another, this is a great example for me to talk about. You, when you make proposed changes, you can also create this for request early. And you can also make it a draft. So that's not yet ready to be proposed to merge. But I'm working on it. And that's a very good practice. You just make a draft and people will see you're working on it. And you can also leave comments in your own code. Clarifying things, mainly say, hey, I did it this way because of this and that. And that that way the reviewer, when they come to see the code will understand right away. Why wrote it that way? So they don't have to ask the question, hey, why did then you write it this other way? Because you thought about this and it didn't work. Okay. Nice. Okay, you added stuff like that. That's fine. Let's go back here. You added some comments. Cool. So if you like this, thumbs up or okay, the reviewer and post that and message with you and converse and so on. Now, one thing that you might notice if you scroll down, because I merged those changes previously, I added new code, right? So that same file, because we are working on the same file, there's the potential for conflicts to arise because I'm changing the same thing. You're changing the same thing. So we have to be careful about that. Now, because my change already went in has been merged, your code is kind of outdated compared to the original. So you can see here this branch has conflicts that must be resolved. Okay. So to resolve this, let's work this out. Typically, whenever you propose something, you have to hold the latest changes. Now, let me show you in the terminal. So I would do this as a, you know, the person who just proposed this. Say you are, you are, you know, our copy here in the terminal. So what you have to do is you have to pull and sync with the original. Now, if I do get remote dash V, I don't have it here. I have my own copy. So I have to add another remote for that original and that one I can do great. We get remote add and we call it upstream. That's just a naming convention. You can call it whatever. And then you have to paste that link for the original. Now to get that, you can click that clone button, but in the original repository. So going back there, this is the original, right? So I can go to code and click code there and copy this. I'm going to copy SSH. Then I go back to my terminal and I paste that there. So get remote add to add a new remote that's called upstream. And this is the link or URL. Now, if I do great remote dash V again, I should see the upstream here. Okay. Now you need to integrate the changes from upstream, the original into your own copy to do that, you do get patch upstream. That means you want to get the latest changes from the upstream one. Remember, the upstream is the one pointing to the original repository. The origin is pointed to your copy. If you do that, you're pulling the latest changes from upstream, which is the changes I merged just now. Now I need to integrate them or merge into my own. So I'm going to do get merge upstream slash master. Now let's see if we have the commit here. You can see there's the merge request and there's the add blank line and what I'm studying. If I kill to quit pressing kill to quit the log going back to visual studio code. I should be able to see whatever was there. I'm taking the point of view of this other person, you who are working with me right now. Okay. Of course I already have it, but yours would be appearing in addition to your thing and probably would have a merge conflict. Would you care to say what you got when you said get fetch upstream master and then you did get merge upstream slash master. Did you get any merge conflict in your code? Or didn't merge everything fine. Or if you do understand what I'm talking about this. Let me know. Okay, so it merged fine. You have my sentence in addition to yours. So if that is the case. Nice. Nice. So if that is the case now you can push your copy. So it's updated on GitHub. So you would go here and say get push. Okay. Now, because it's your copy, you must specify its origin, not upstream. Okay. Origin and then master. It's the name of the branch to do that. So it's in sync. Okay. You should be on your fork. Are you in your fork here? And you've merged. So where's your sentence? It should be there, no? In the file. In addition to mine. Was removed? How is that possible? Didn't you see a merge conflicting? Anyway, let's see. Let me try to demonstrate what you would see here. So back here I copied your message. So basically what would happen typically if there's a merge conflict, it would appear something like a bunch of equal signs and then it would be your version and it would ask you if it's visual aesthetic code, it would ask which one do you want to keep? Okay. And typically this is called a merge conflict. What you want to do is remove and look at this one version and the other one version. And if you think having this is fine and having that is fine, I know we want both, right? If we want both, remove the, either click, there's an option here, accept both, or you can manually remove these equal signs yourself and combine them together like that. Make sure there's no equal signs. Okay. When you save that, that just means you resolve the merge conflict. Okay. So I put yours, it's either before or after, it doesn't matter. But this one I put after. So you would see this. And then what you would do is on the left-hand side of visual aesthetic code, if you're using that, you would just add that, get add, and then you'll finally commit here to resolve the merge conflict and click commit. And then finally you want to push it. In the terminal, it will be get push, origin, master. Now, if you want to do from this one, you can also do the triple dot and click push. But I don't know if it's going to understand if it's upstream or origin, so it's better to do from the terminal. Okay. Once you got that in and commit, in the terminal, get push, origin, master. Okay. Did you push that? Let's see. Make sure you commit that and push. Once you, you have two, then all, both of them together in the code base. Click to add and then commit those changes and then push. I'll post the commands again if you're in case. Something like that. If you don't want to do it, the graph go away. Okay. Now I see going back to GitHub, you can see refresh appeared here, so I'm going to click or I could refresh in my browser. I see this is here, but it seems like if I look at your commits just now, looks like you just removed the line, but there's not my line. Did you remove that? You should keep my line as well. Shouldn't remove them. Let me look at your branch here. I'm looking at yours and this is test. Okay. No problem. Let's look at it together. You got lost, but I'm looking at your repository copy. They are fork and I'm going to go and see your commits here and I'm going to look at the history. Okay. So I can see I add a test file, change world, whatever. Add line as a stage and then you did some changes here. Okay. But looks like you didn't integrate my commits. So you must integrate mine into yours. Okay. So you're missing my commits. So like, like I said, to do that, let's go to the terminal. Okay. Here you are in your copy, like your username slash introduction to good. Right. Now do get removes dash V. Did you add the upstream pointing to the original one? You see the namespace owner is different. It should be MVK tech world there. Do you have these two? When you do get remote dash V. Yeah. So could you go up in a terminal and let me know if you have the upstream remote setup. If you type get space remote space dash V. You're going to see something like this one for origin, two entries for origin. And I added two entries for upstream, which means pointing to the. Yes. Let me see. You have origin. That's pointing to your copy. You have upstream. That's right. Okay. Now what you're going to do is get fetch upstream like this. Enter. This is going to pull like take the update. Okay. Now you got those. Now you need to integrate into yours. Okay. You're going to do get merge upstream slash master. That way you integrate the changes from the original into your copy. Do you, do you get any message about conflict at all? Or did they just work? What does it say here after you type get merge upstream slash master? Yes. It should say conflict. Correct. Now we have a conflict to resolve. Now to do that, go to visual studio code. Go to the file. Right. You're going to see a bunch of stuff like equal signs. Like this. Something like this. Right. Do you see the equal signs? Do you see my message? Do you see your message? Yes. To correct this, resolve this conflict, we must have both messages. Therefore, take the equal signs, remove them. Remove the equal signs and combine the two messages together. That way we keep both changes. My message and your message. After you have them like this without equal signs, save the file. Okay. Now we have to add and then commit again. Typically, if you're in visual studio code after saving the file and clicking the version control icon, you're going to go here. I don't know if it's in changes or staged. If it's in changes, just click plus. Okay. You should see it in staged changes. You should see my message and your message here. Do you see that under staged changes? Once you see that, click to write a message. Resolve merge conflict to describe your resolving the conflict. If there's already a message here, leave it there. It doesn't matter. Yeah. And then click commit. It's probably going to have a message already there. Merge whatever. Just click commit. Once you click commit, I want you to go to the terminal again. And you're going to say get push origin master so that you push those new changes that you integrated from the original to your own copy on GitHub. Get push origin master. Okay. Let's have a look. I'm going to get help to see if you sent the comments. So I'm here. I'm going to refresh. Okay. Resolve conflict just now. Okay. Aha. Aha. There you go. Ah, okay. Now you got it. Almost everything is right. Do you see this, this thing here? I forgot to tell you about this. Sorry about that. I just said equal signs, but there's actually more stuff. So all this stuff that was inserted here is from the merge conflict resolution. Yeah. So you want to make sure to remove this and remove that. So just for practice, I'm going to review your code to say, could you remove these conflict lines? Also in the bottom, this thing here, I'm just going to copy exactly. So you understand what I'm talking about. And then we're going to copy this exactly. So you understand what I'm talking about and I'm click add single comment. Okay. I left you a feedback. I want you to go back to visual studio code, remove what I told you to remove, which is the last then had line four and remove line seven greater than upstream slash master. Okay. Remove those. It's not necessary. That's just from the merge conflict resolution thing. Okay. Once you do that, I want you to commit again. Remember, click add to stage the changes. Then you're going to commit with a message here, remove, you know, conflict resolution characters or whatever, and then click commit. Once you do that, I wanted to go back to the terminal and do get push origin master again so that you change, you send those changes to get hub again. Okay. Once you do that, we're going to be able to refresh the page and I see that you remove them. Nice. Now I can see my review that you added this line and my line is also there. So I'm therefore I'm going to approve it. See, click review changes, approve and submit my review. Typically, people like to say looks good to me, LG TM for short. And some like a rocket to ship. You're good to go. You can ship these. Nice. No conflicts. And I'm going to click merge per request, confirm merge. Now we integrated your changes into the original. Okay. Now, once we do that, if I look at code for the original, I can see that your name is here. Nice. Okay. Before we wrap up this lecture, thanks for your patience, by the way, we're going to go here and clean up our local. Okay. Make sure to clean up our local environment. Go back to here. You're going to sync with the original. In your copy, you're going to do get fetch upstream again. Because remember, I just approved and merged your changes. Therefore, the original now is out of sync with our copy. So you must fetch from the upstream, which is the original. Get fetch upstream. And you see there are some changes there. Now we need to integrate into our own copy. We're going to do get merge upstream slash master. And because I changed some stuff, it's complaining. Let me just quickly remove what I was doing here. I'm going to take this out because I was doing your line. I'm going to revert back to my own. You don't need to do this. Going back here, I'm going to try again. Get merge upstream slash master. And it fast forward here. That means my local copy is now in sync with the original one on GitHub. Now I must push my local copy to my fork on GitHub. So it's also in sync. So I must do get push origin master. Okay. Origin because this is mine. Okay. My copy on GitHub is called origin here. Once I do that, now my local copy is in sync with my GitHub work. So I can go there and verify if I go back to mine, right? This would be under my name here. You can either type it here. I think you can look at the forks if I go to from the original. I click here. This is my fork. So I click there to go there. Now this is my fork page. I should see that this branch is up to date with advocate tech world the original slash introduction to get. Okay. You should see this message meaning they're both in sync. Okay. That's how you clean up and sync everything. So you're both on the same page. And I can I can go to the comments history and you are here. So I verify it's here. I verify that your thing is also here and so on. Okay. To finish off, like I said, we just did everything on master, but typically we wouldn't do that. We would create a new branch with we would branch off master work on those new changes for yourself on a new branch. And then you propose though that poor request to be merged into master in the origin. Okay. And then later you get rid of the branch and clean everything up. Okay. But that's a topic for more advanced stuff. And that's that's it for this lecture.