 Welcome back to our channel. Today we shall be talking about git push, which is one of the ways that we send our code online. Now that we've finished making our changes in our local repository, in our branch of our link edits, we realize that now the whole point of actually making the branches so that we can make changes to our code and then send it back online or in another repository so that we can have it merged. So what we're going to do is actually push this up online and what we're going to do is by typing git push, dashu, origin, origin being the link of our folk repository. And we get an error here. The branch is telling us, you know, you don't only need to add the link of the repository but you also need to add for which branch that you want to send this. So it will give us an error message and also give us a solution. So we'll type our git push dash dash set dash upstream so that we can stall for upstream in our git and then we'll add origin and then we'll add the branch of the fork, which is link dash edits. So once we hit enter, we will have our fork sending all this information up onto the repo. However, this origin like I told you is actually just the link of the fork that we do have. It's automatically set by git as the name or like the shorthand name of that link. And once we go online, we realize and go to our repo and refresh it and look in our link dash edits branch. Our edits have been made and we have actually just one commit ahead of the master branch of our original repository. So what we're going to do now is actually compare the code that is there by clicking the compare and pull button, repress button and then there we'll ask for the maintainers original software whether they should actually allow for this new edit to be added. So what we'll do is we'll look at our comment section and it's all written in Markdown. However, we can check off this list by adding the access to the particular brackets and Markdown is something that's interesting. However, we're just going to check on what's right. So we'll check our options that are available and we make sure that we're providing full information and we can actually see the information we are submitting by clicking the review tab. And by going back to the right, we're able to make more changes to our comment section. So we'll add some proper messaging to allow the person reviewing our pull request to find out the meaning, the purpose and the changes that are involved actually in our pull request so that they are not lost into finding out the reason why this person made this pull request or figuring out why the code changes are so. So that's the whole purpose of the comment section to make reviewing of code a lot easier. So we need to write some full content comments that leave no questions to the person who is actually maintaining that particular code base for them to make a proper analysis and also to give proper feedback. That's one of the things that you will see. So once we review again our changes that we've made realize that we're on the right track. So whatever we actually don't need wherever we don't have answers in this response template we just need to make corrections of it and then we'll have something that's minimal and something that is acceptable by the maintainers. So right now we'll just add some changes to show what's happening in this pull request and how they can replicate and see what particular changes we've made and how they can test them. The good thing is that I don't have to write a particular test for the change I've made. It was mainly editorial and just making a simple change. However for some of the changes that we do have we actually realize that they need to have proper tests. Let's say if they are in JavaScript or any other language we sometimes have to make those tests. So we'll complete up our form filling in the necessary information and then we'll submit the pull request by clicking the pull request button. So we will share that we have also made some local tests that we've done. That's why we're able to recreate the particular two steps above to show what to do in case you're testing the changes and then we'll just add a simple change log that can be put in the notes of the upcoming version of the software. So we'll just copy that and paste down here and since it's the same and then we'll preview our notes to the maintainers. If we see that actually everything is in place then we are actually good to go. So we'll just hit the pull request button and our message will be sent to the maintainers of the software. So the pull request is in in the proper place that it should be and we can see a number of other pull requests that have been made including ours. So you can actually view it again see if you've made any errors make any edits to the comments and notes again so that you allow a proper review of the changes you've made. Now one of the things that Agitator says people who contribute open source software is that sometimes we're not patient but I urge you to be patient whenever you submit a pull request allow time for the review of your code and allow time for the maintainers to do some testing. So don't go calling every five minutes just make to see whether everything is okay but it's also okay to ask maybe after a couple of weeks or days if something has not been pulled in. So thank you for watching the video please ask any questions that you feel uncomfortable or please submit anything that we should be adding to the channel. Thank you for watching we'll be finishing up our series shortly so we hope to catch you in the next few videos.