Summary of Collaboration on GitHub

Now, I'm going to talk about collaboration on GitHub. Let's suppose you want to be a contributor to open source. How would you go about that? Well, first you find the repository of interest. Let's suppose this is the one that we're working on. This is the one. And then somebody would have maybe an issue there that the maintainer of the repository would create. Maybe they want a new feature. So they would add here, maybe add a third sentence to test.txt. That's the feature. So they would have all the issues created. So you just would browse through all the issues and see what you could help with. And if you find this one to be of interest, you would just ask here, hey, I would like to help. So the moment you comment, the maintainer can now add you as an assignee here. So from their point of view, they would say, okay, this person want to help, let me assign them to this task. Now it's important to keep in mind you should never start on a task before you're assigned. I've seen that a lot. People who are newbies, they would just look at an issue and right away they would try to come up with a solution and submit that. That's a problem because what if other people also did the same, you would be wasting time, right? And the maintainer would know, okay, who am I going to pick? And it's going to be confusion. So you want to always be courteous and ask first, hey, I would like to be assigned to this task. And when they assign you, it's when you start to work. And you can start working on that. And I'm going to walk you through the workflow. So basically, because you're not the maintainer of the project, you would have to create a copy of it, your own copy of the code, and then work on that and then propose changes to the original one. And that's called a forking, okay? If you're working in a company, you wouldn't have to do that because you have permission to work directly on the repository. Or if you're the maintainer himself, right? So what you're going to do is create a fork. So let's see if I can create a fork of myself, I don't think so. Maybe I'll create this in the other one. Let me take another one here. Yeah, this one, about this, but that's a different one, but whatever. Let's assume this is the same one. So this is what I would do is click fork here, okay, work your own copy. And forking is basically a GitHub function that creates a copy of the repository, your copy. So I would go here and click there and already have it, choose a different name and click create fork. Let's do that while I'm at it. So this is my copy and this is the original, okay? So basically what I would do, okay, I got my copy now, I got to bring this to my local. So let's go here to the terminal, okay, so let me clear. So basically I would CD out, and I usually like to keep my username here to match what I have on GitHub, otherwise I'm going to confuse who owns what. So I always have a directory of the same owner. And then I can go here and get clone to download my repository. And I got to copy the that same SSH thing. If you go to GitHub, you click code, SSH copy this for your fork, your copy. Okay, I already know it, so get GitHub.com, user name slash production, you get for dot gates. And I can verify get remote dash V after CD, first you got a CD. Oops, not that one for. And then I got to do remote and that matches. Okay, so I'm going to code dot this, because it's a different repository. So let me open in a new shared. There you go. And I'm going to open terminal here for convenience. So I got that, this is my copy. So I would go here and start by doing a feature branch. Right now I'm a master, by the way. Check out branch dash B. Let's say describe whatever that issue asks me to do, I think add third sentence, right? Let's see. Add third sentence. Yeah. Add third sentence. Now in my branch, I would go to whatever file it is this one, third sentence. Then I would do the get add, and then commit. But let me show you a graphical way of doing that. If you are in Visual Studio Code, you can click this search control icon here. And this is basically the get status. You can click here for a get a diff. And you can add with the plus to stage changes. Now it's been staged, you can add the commit message, add third sentence and click commit. And that's equivalent to get commit with the message. And if you do get log, you should see your commit here. So with that, I can just do get push. And then in this case, it's not master. It would be origin, the name of the branch, add third sentence. If you don't remember the name of the branch, get branch. Then I would go, let me just make sure I'm in the right place, which one? I think this is the one, right? So I would go there to my copy, my fork. And I would see this compare and pull request button that I can click. Or you could go to pull request either in the fork or the original and click pull request and create new. If I go through here, it will have this thing that you got to pay attention to. So I usually read from right to left. Okay, this is my feature branch in my copy, my fork. That's going to be proposed to be merged to the master branch of the original one, which is owned by NBK Tech World. And then I would describe my, this is my pull request code proposed, the proposal of changes. I would describe it, the title here in my description, I usually put a resolve number of the issue. And one, two, three or whatever the number was, because I created in a different one, it's kind of weird, but I should create it here in the original. Let me do it that quickly. This is the original. I'm just going to do the same thing I was doing there, create the same issue. Like that. And add myself here. I'm going to work from this branch, this repository instead, because I already have a copy of the other ones. I don't want to do it myself. Anyway, going back here, this one is number one. So I'd go here and say, okay, result number one, it would usually appear, let me try to refresh. Number one, yeah, usually appears when you type the hash and the number and you press enter. So that way, when if I click preview, it's going to link to the issue that I'm working on. When you propose the changes, the other person has to know exactly which issue this is tackling. So it's important to have that there. First thing as a description. This is the title and this description. And then you would go on to explain what your change, what you're proposing. Here, I add the third sentence to the test file. And you go on to explain what you did. If you had different alternatives that you considered, maybe you consider doing this a different way, but you had trouble, you want to document everything here. And then you would say things like, what are the risks? If this goes to production and something happens, what's the way we can roll back or mitigate the changes? Is there a workaround customers can use if in case this breaks anything? And so on, you can list all the things. You can add even a screenshot here. Let me add a screenshot. Usually it's nice to have something visually. You have a screenshot there. People can right away see what you did. And so on and so on. Okay. And then you click create pull request. Usually, somebody would be assigned here to review automatically if you have everything set up in your company or the maintainer set it up. But if not, then somebody would have to manually go here and see all this stuff. So basically it would be somebody else that would review, usually not yourself, unless you want to break the rules in a startup environment. But usually somebody else would come in, okay, somebody proposed some code changes. Let have a look. In that switched contacts, I am the reviewer now. I'm doing the code review. So I would look, okay, read the title to understand what's doing. Okay, you're resolving this issue. If I want more information, I would go there and read about the issue. And I understand what you did. Okay, let's see the files changed. Okay, that looks nice. If you find any trouble, the reviewer would comment on the line pressing the plus. Did you add a period, for example, and add a single comment here, or you can do a review. And then you give it back to the person who was working on this. Let's switch contacts. I'm now the person, the developer. I would read this and see, okay, okay, I want a period. If you disagree with this, you could go on. I disagree because blah, blah, blah, and keep going back and forth. Otherwise, okay, let's, let's fix that. So what I would do is I go back to my code. Okay, let me close that. Here's the file. I'll edit the period. Nice. Let's do allow for the command line. Get status. Okay, get add test.txt, get commit dash m, add period to third sentence. Quotes there. Enter. Now I've made my change. Now, all I have to do now after addressing feedback is push to the same branch. Okay, get push, origin, add third sentence. Now, in previous boot camps, people always have the same question. Do I create a new feature branch when I address feedback? Do I create a new fork? Do I create a new pull request? And the answer is no to all of those. You always use the same feature branch, the same fork, the same for request. So all you do is add new commits locally and push the same way. And then you go back, and when you look at your pull request, GitHub automatically will detect that you added a new commit here. See that the dot is there. If you click files changed, it will be there, the dot. So once that is done, you would go here. Usually there's a thing here that you press to ask for another review. Let me see it. And you would click here and ask for the review again, and then the reviewer would come in, okay, let me review this. By the way, if you think this is resolved, you can click resolve conversation. And they would look again, okay, that looks good to me. They would go here and approve, click approve and say, usually looks good to me, I'll do GM. Obviously, I cannot do it for myself. That's why it doesn't allow me to, but I would click approve and then approve it. Once it's approved, now, depending on the company or if it's a maintainer. If you're working a company, you could merge it yourself. If you're working on the open source, probably the maintainer that has to merge because you don't have the permission to do so. So in this case, I am the maintainer. I would go here, okay, I'm going to merge. Once that is merged, these changes are now integrated into the original repository here, this one. And I can see the history. Now I have contributed to this open source project. And if I look at the file, it's there, my contribution. And what's nice, you can see, you will appear as contributors here eventually. And there's also this inside stab. There you can see the contributors to the project and many other stats. So it's very interesting to know who's the top contributor. This is me. And you can see the forks here, that's cool. Who furked this. And here my copy. Anyway, now that we've done that, we got to clean up. It's always something that people forget to do. So once you get your thing merged, the first thing you got to do is you got to delete your branch on GitHub, your feature branch here. Usually from the pull request page, you can click delete branch there. If you don't know, you can find this. You can always go to your fork, let me click here to go to my fork. Click this arrow and that. Go to your fork, make sure you always know where you are. I read this thing here, I see this is my fork, because it's a fork from. And I'm going to look at my branches by clicking, where's the branch thing? Let's see, branch behind. Oh my gosh, where is it? Usually there's a place where I click, oh here, there you go. And I can see the branch here, and I can delete with a trashcan. But make sure you delete your feature branch, not master. I keep saying this because I don't want people messing up. Never delete master, okay? Never delete the main branch. And there you go, I deleted the feature one. But that's just GitHub, I got to clean up locally. If I go back to my local, you see I'm still back in time. I still have my branch here. So what I do is always like this, check out master. Then I have to first sync my changes with the original. And that's where people get confused a lot, because it's kind of tedious. So right now I have my copy or fork remote. But I actually have to add another one, which is pointing to the original one. Because the original just integrated my changes, and I don't have it in mine. So I'm going to add a new remote by git remote add. And we usually call it upstream, which is like the original. And then you go and copy that SSH thing, let me show you again. If you go to the original, this one, you are in the original, click code and copy this one from SSH. And then you go back to the terminal and add that here. Make sure it's the original, not your copy here. And that's the upstream one, if you verify git remote. Dash V should add now four, two for origin, two for upstream. And you verify that this is actually the original and this is your copy. And what you do is you're going to pull the changes fetch from upstream master with a space. But that doesn't yet integrate those changes into your master. So you've got to do git merge upstream slash master. See the slash, because this thing is actually a branch name. When you see upstream slash master, that's the remote branch. And now you integrated the changes into your master, your forks master. Finally, we have to update our remote. We have a copy of this, right, a fork in GitHub. So we got to push it there too. So git push origin master. That way, when I go back to my GitHub copy, which is under forks, I can see now that I'm now this branch is up to date with master from the original. You're going to see this message here once everything is in sync. Okay, got the commits there. And here's the commit. So that's the process. Obviously, it's much simpler if you're working in a company or you already have permission to the repository. You don't have to have a fork. Okay, so basically, let's see if I can try to draw. I know it's a bit archagrasp. Basically have origin, let's see if this is an upstream. So our origin, our fork and upstream is the original repo repository. So we have the origin one from the our point of view is our copy or fork. And we have the upstream remote, which is the original. So usually we have our master in local. And what we got to do is always check out master. Then we want to bring the changes from upstream here to our master. And then we have GitHub here, right, GitHub. And then once we integrate the changes into our master, we got to send that to our GitHub thing. So it's kind of weird process. We have made a proposed changes to the original, the original merges. And then what we got to do is fetch from GitHub's original into our local and then merge to our local master for our copy. And finally, we got to push our master local to GitHub. So everybody on GitHub sees. All right, then once we're done with that, let's make sure to also clean up the task that we got to do here. Let's see, not that one. Sorry, this one. So we got to go, okay, to the issue we were talking about. And we got to make sure the issue is closed. If you need to message anything, you would say it here. And then you go here and close it. Now, the reason this one closed automatically is because we typed resolve whatever in this description. And when you do that, it links this pull request with the issue. If you see on the sidebar, they're linked together and there's automation there that closes this as soon as the pull request is merged. But that might not always be the case. So we got to always make sure to look at the issue and see if you don't have anything else to handle there. Another thing you're going to see a lot is, let's go back to the one I was doing before, that's different one. And actually, I want to go to our repository for the bootcamp. And I want to show you the project's function of GitHub. So what you're going to see a lot is this project's function, which is basically a combo on board. And this is very common in when you work in a company, in a team. Here, you would see the issues in a board. For example, right now I'm doing this one. So I would have the to-do column in progress and done. Right now, I am doing this one. So if I were to start on that, I would get assigned and then I'll move to in progress and right now I'm doing it. And then you would also see other people's issues here too. Let me see if I can add some of them here. And click this. I will add all of these. Basically, everything that needs to be done, the backlog, would be here. And there would probably be different people working on different things. Usually, this board would be brought up in what we called a stand-up meeting that we usually have every couple of days during the week. And the manager would go, every person would say what they did, what they are doing right now, and what they're going to do if they have any blockers, that kind of thing. So you could see clearly who is working on what. And yeah, so basically once you're done with that, you would move to done so that at the end of the iteration, after usually two weeks, you would see what was done and people would grab new things to work on. So yeah, so let me give an example here. Let's say I were to do this one. Okay, I somehow got assigned to do this. My name would be here. I would start working on it, submit the request. Once I'm working on that, I'll be under it in progress. Once I'm done, I would move to done like that. Make sure to also close the issue because usually the board is separate from the issue itself, but I see there's some automation here. Whenever I move to done, it marks it's completed. So that's convenient. Anyway, that's how you would do it. I'm going to move back because that wasn't really done, and I'm going to reopen it. Yeah, so that's GitHub. So if you want to find projects, collaborate, maybe you can go gethub.com slash explore, see what they have there. Maybe you can search. Maybe I want to search for a Visual Studio Code. I wonder if the code is available. Oh, it's here. So they have VS Code, and if I want to contribute, I could go to issues and see if there's something I can work on or I can report bugs. They have also these things called labels that you can filter by. There's so many of them. If usually a label for beginners is called good first issue, and that's something that could be something somebody could start on that you usually label. Oh, this one is a bug, good first issue. I'd go there, read about it, and then ask to do help it out. And then you would get a sign like this person, then you would work on a fix and submit the progress like they did here. They even put a video here, and they put the files changed, and this is what they did for the change. Then somebody would review this, comment on it, and approve it. It looked like it was approved by somebody. As you can see here, there's some continuous integration stuff, CI. That's what I talked about before in a previous session. Basically, the code changes that were proposed. It's running a lot of tests and stuff to make sure it doesn't break anything. So it's reading that one. They were waiting status to be reported. I don't know what's going on there. Something happened. But basically, it blocks the merge until all these pass. And let's see some of the ones that were actually merged in. If you click here and go, let's see the closed ones, this one. Somebody fixed this issue, and these are the changes, and they got approved and eventually merged. Okay. What is? If you have any questions, let me know. So this, if you, you might see other competitors at GitHub as well that do the similar feature, Atlassians, Bitbucket, Jira, they have heard of Jira. Many people hate it. GitLab. So they pretty much have the same kind of functionality, although they call it different things. All right. Let's work on a feature of the Orbit Camp. So I created some features for people that like to contribute. So if you go to the Orbit Camp website and click issues, there's a lot of things we could, you could contribute to as practice. So you would go here, for example, sign in form. Let's say you want to help with that. So basically it would comment, I want to help, comment there, and I would go here and assign you, and then you can start to work. And you propose the changes with the forecast and so on. So basically follow the same approach. Let me show you. Let me walk through it again. Let's say, let's add header to index. How about that? Okay. I want to help. And then you get assigned. And then now you can start work. Okay. Let me first fork this because I don't have access. So I'm going to click fork, create my fork. Great. I have my fork. Now I got to clone this because I want to have the code for myself. I would go to the terminal. I would make sure I am in my username directory. Otherwise they confuse who's owning what. So I always make sure to mimic the same name as GitHub. Now do get cloned in that link. And I just cloned my copy, my fork. So I go CD to that. Open VS code. And I'm here. Create my feature branch. Make sure you're a master. I know I'm a master already. If you're not unsure, get checkout master. Doesn't hurt. Get checkout dash B. What is it? Add header to, what was it? Add header to sign. To index page. Yeah. Index page. So I go here. I understand. Okay. There's source index. I got to add a header. Here is the body. I will add a header, which is usually on the top of the website. And site title. I don't have a site title. I'll just put it there. And maybe I want to add a class to add some styling, site title. Then does this have, I think this should be the same across all pages. So I'm going to add to global. So I'm going to open global to the side. I'm going to add the class here definition of selected element that has the class site title. And maybe I want to add some padding. That's the space within. So it's not so close. Different background color. Maybe light gray. I think that's, that might be enough for now. I can do a preview here. Portrait of shift B or click view. Command palette. Oops. Live review. And see it looks like that. Yeah. It looks okay to me. If you want to tweak, you can do it. And then you can keep working on it. Add the files. Let's do the dash dot dot just current directory. So do you like this? Yes. Yes. Great. Get status again. Okay. This is your model file. Let me add commit add header to index page. If I want to keep going, I can change new things and make commits. Maybe I didn't like the site title. Maybe I want to say post stack web dev. They'll go get status again. Okay. Get add. Then I'm going to say a rename site title. So far to commits, right? You can go on and on and on making many commits. Once you're done. Remember where you are in the branch. You're going to do get push that you want to do that shoe. That's fine. So you don't have to do it the next time. Origin. And then here you had to do branch name, not master, right? And that's going to send the code, the branch to get hub. So we go back to get hub and remember the issue name is five. So we can go here to the code section. Make sure you are in your copy, but actually from here also works from the original. It also see this. So either way, if you don't want to do through this one, you got to go. For requests, click new. And then you got to figure out what do you want to merge? For example, I want to get the one from the other one. To this is probably you got to do it from your copy. Let me do it for the copy. This way is kind of weird from there. So we go here forks, my copy. And then you go for requests new. Let's see if it allows me. Yeah, that's here. So you make sure to select the feature branch. And your copy. And then it goes to master of the original. See that that button in the yellow banner is just a convenience for already pre select this. And then you verify, okay, these are the changes. Nice. Create for requests, add harder to index page. Maybe I want to add a screenshot to show what it looks like. Like that. I just control C, control V. After press on windows is Windows key shift S. And then you can select the area of the screen to screenshot on Mac. It's, it's a, the command shift for number four. Anyway, I've got to write the description right. This poor request adds a header section to the index page. I use light gray for background color. And added some padding if the styles. In the issue, it didn't tell me what styles exactly were requested, right? So maybe I could backtrack and, you know, before I had done my feature, I could have gone to the issue and asked, do you care what specific style you for the header, what background color, etc. You would comment here, the other person responsible for this would reply to clarification, what you got to do, and so on. But you can also do that in the poor request. If the style is not suitable, let me know, and I'll change it. And then you can go on explaining this change would affect the landing page. Which is what customers see. First thing, I don't think any trouble will occur. I will make sure to test in staging environment, which is basically an intermediate environment. That's not production that you launch to to see if nothing broke. In case of problem, get to revert the commit for the PR something like that and then create. Then somebody would be paying to review and ideally you want to add this to the board as well as you're working through, like the issue here if you go back to the issue page. I can click projects here add to a board and make sure it's a change to in progress. And if you go back to the board, you should have a feature you see this one that I'm working on at a header. It's there. You want to make sure it's there as well. And then you work on it. Somebody will review. Okay, let's say I am the reviewer. I would go here and say, okay, let's create. Looks fine. And then maybe if you were unsure what they wanted for the background call, you could comment here as well. The reviewer is not the only one that can comment you as the one that will propose the changes can go here. Should I change this to something else? You could ask that early as much as you can any line and then the review would go in. I think it's fine that color. No need to change. And if everything's good, they'll just approve here. Looks good to me. Submit the review and then some see I would run to make sure nothing breaks all the tasks past and you can finally. The main term would merge or you can merge yourself if you're working in a company and have permission. Okay, I think it looks good. Right. And then we follow the cleanup process right again, delete the branch or get hub. Then you go local. Check out master. Get fetch upstream master. Oh, I forgot to add upstream right you got to add upstream to get the remote add upstream. Get at github.com. Oh, it's not into reductions. Let's tag up that dash to get. I think that's it. Let's try again get fetch upstream master and then get merge upstream slash master. Now I got the changes. And then finally to update my copy on github get push origin master. I just paste that to you because maybe it's confusing every time but it's always the same. You remember get fetch upstream master get merge upstream slash master get push origin master always the same. Some people like doing get pull which is basically batch and merge at the same time so you could do that get pull upstream. Oops. Like that. That's that batch and merge at the same time. And then we do the get push origin master. Anyway, that's the I guess the approach and then and then make sure your future branch deleted here get branch dash the you don't need it anymore. I want to clean up. It's gone now. Oops. All right, so feel free to grab any of these issues if you want to work on on our page. I just go there select an issue asked to work on it and I'll sign and you can work and propose the poor request. But yeah, I think that's it for this lesson.