How to create a Pull Request on GitHub

[00:00] We're finally ready to start making our changes to add padLeft to the project. Let's review the contributing guidelines in the contributing.md file of the project. Here, we've already run NPM install, and run the tests and the build.

[00:14] Now our next step is to run NPM run test watch. If we run "NPM run test watch," then we're going to see that it's running all the tests, and watching the file system for changes to rerun the test as we make changes to the files.

[00:30] Let's just verify that this is working by opening up our editor. We'll open up one of the files, and we'll just add a new line here, and hit save. There, it reran the test. Everything is ready for us to start contributing to this project.

[00:44] Now we're going to want to look at the acceptable contributions information to find out more information about how our contribution should be accepted. It's also wise for us to look at the other methods that have been implemented, and implement ours in a similar fashion.

[01:00] We notice that flatten has an export default of the function. Then it has the function definition, and it has the documentation in here. We want our code contribution to have the same style as the other code throughout the project.

[01:13] This is definitely something that we want to take note of for our implementation. I've skipped ahead a little bit here, because the actual implementation isn't really necessary for this lesson. If we look at the Git status, we'll see that we modified the source index.js, and added these two files.

[01:30] If we look at the Git diff, we'll see the modification to the index.js was simply to import the padLeft function, and then export it. We can go ahead and take a look at padLeft. This is formatted just like we need.

[01:43] It is using the function that we discussed with the project maintainer. Then we have this padLeft test that follows the standard for the other tests in the project. The problem is here there's one thing that we couldn't quite figure out for our specific scenario.

[02:01] That is this project requires us to have 100 percent code coverage, and we didn't quite meet that standard. This is a fairly common scenario when you're contributing to an open source project. You have part of the implementation done, but you're not quite certain how to finish the entire implementation.

[02:19] What we're going to do is we're going to commit what we have and create a pull request out of that so that we can iterate with the project maintainer to get a little bit of help, and a little bit of direction, to make sure that we're taking this solution in the direction that the project maintainer wants to accept.

[02:35] To do this, we're going to Git add everything. Let's take a look at our Git status. Now we'll run Git commit with the message, "Work in progress. Cannot get coverage quite there." You'll notice that in this project, it's actually running a series of Git hooks.

[02:56] Git hooks are some scripts that you can configure to run during certain parts of Git, like when you're creating a commit message, or when you're pushing to a repository, or committing some code. Many projects don't have Git hooks.

[03:09] Don't be alarmed when you some random scripts running, when you're interacting with Git in a repository. If you're ever having trouble with a Git hook, and you still want to push your changes to ask for some help, just simply add the --no-verify flag to whatever command that you're running.

[03:25] It will skip all the Git hooks. That way, you can get some help. Now we're going to push this up to our remote repository, to our fork. Then we'll create a pull request. To do this, we have to run Git push, but then Git needs to know where to push these changes to.

[03:41] We're going to say origin, which is the name for the remote that is assigned to our fork. Then we need to tell it which branch on that remote to send our changes to. This will be the same as our local branch, PR/padLeft.

[03:57] It can get cumbersome to specify the remote that you want to send your changes to, and what branch to send it to. To specify the upstream for a particular branch, you can say, "Git push --set upstream," and then specify the remote that you want this to be tracked against.

[04:18] For us, that'll be origin. Then the branch would be PR padLeft. In the future, that's the first push you would specify the upstream. Then you wouldn't have to specify the remote branch that you're going to be sending these changes to.

[04:34] As a pro tip, this set upstream can be shortened to -u. That's the command that you would use for the first time that you push to a remote branch. We can go ahead and do that now. Now that branch is set to track remote branch PR left from origin.

[04:50] Now we no longer need to specify origin PR padLeft. We can simply say, "Git push" when we're on this branch, and it will automatically push to the right branch on the right remote. Now on the GitHub repository, we'll see that GitHub recognizes that we recently pushed changes to this branch.

[05:06] We can instantly compare and create a pull request here. However, this only shows up for about an hour or so. If that's not showing up for you, the other way to do this is by clicking the "create new pull request" button.

[05:21] Then you'll want to compare across forks, change your head fork to your fork, and then change the branch that you're comparing to the branch that you just pushed. Then you can create your pull request. You give a subject.

[05:35] We can leave it as the default being the message of our commit. Then we can add a comment here. You'll notice that in the comment for this pull request, I've added as much information as I can about the help that I need.

[05:46] This is really important for project maintainers. Many of them are really busy, and are doing this on their free time. You want to be as helpful as you possibly can. With this comment, we'll go ahead and click create pull request.

[05:59] This will create our pull request. We can look at our files changed. This is the difference between the base branch, and our head branch that we want to have merged into this repository. Now we patiently wait until the project maintainer has a moment to look at our pull request, and give us some feedback.