Save 45% for a limited time.

Get access to all courses and lessons on egghead today.

Autoplay

    How to Collaborate on a Pull Request on GitHub

    Kent C. DoddsKent C. Dodds

    It’s not often that you’ll get a Pull Request on GitHub just right the first time you try. You generally will iterate with the project maintainer on your solution before your PR gets merged. In this lesson, we’ll explore some of the tools that projects use to manage contributions to open source projects on GitHub.

    gitgit
    githubGitHub
    Code

    Code

    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    Transcript

    Transcript

    00:00 We've patiently waited. Now, the maintainer has gotten back to us.

    00:03 Before we look at the comments, let's look at some of this information in this poll request. The first thing interesting is this comment from Codecov.io bot. This project uses codecov.io to report coverage. Codecov will comment with the coverage change with each poll request.

    00:19 It's not totally common to have a bot automatically comment on poll requests, but many major opensource projects on GitHub do have and use bots. The React, Angular and eslint projects all have GitHub bots, for example.

    00:32 Often, they'll comment to make sure that you've done something, like sign a Contributor License Agreement, or CLA, which pretty much just grants the project owner all the rights to your contributions.

    00:42 If we scroll down to the bottom here, skipping the comments, we'll see some more information about our poll request. GitHub has a poll request status API, which service is used to provide the information about the poll request.

    00:53 Here, we have codecov reporting that the poll request itself doesn't meet the standard target for code coverage. Because the poll request lowers coverage for the entire project, it also is reporting that the status for the project coverage doesn't meet the standard for the target code coverage.

    01:08 This last one is coming from a continuous integration service called Travis CI. Continuous integration is an automatic process that checks your code. It's common for projects to check code style, run tests, and even run a build using a continuous integration service like Travis.

    01:21 Because the status from Travis CI is green, it means that the code passes all of the checks put into place on Travis CI. We can see that the only thing that we need to update is our code coverage.

    01:32 Now, let's look at the comments from our project maintainer. We can see that this first comment appears to be inline with the code. This is because GitHub has a feature where you can comment on specific lines in the git-dev.

    01:44 If we go up here to the files changed, and scroll down to that area of the code, we can see that this comment directly inline with the code. It's a really common practice to comment directly in the dev on GitHub, because it makes it easier for comments to be in the context of the specific code that's being discussed.

    02:02 You can also comment on the entire PR in the main comments area. If we go back to the conversation tab, scroll down to the bottom, we see that the project maintainer has done this. We can comment at the very bottom here.

    02:14 Now that we've reviewed the suggestions from the project maintainer, we can go ahead and make our changes, and then, update our PR with those changes.

    Discuss

    Discuss