Introduction to GitHub

Exploring GitHub

Exploring a Repository

How to install Git SCM

How to authenticate with GitHub using SSH

Identifying How to Contribute to an Open Source Project on GitHub

How to Fork and Clone a GitHub Repository

Setting up the project locally

How to create a Pull Request on GitHub

How to Collaborate on a Pull Request on GitHub

How to update a Pull Request on GitHub

How to rebase a git Pull Request branch

How to squash multiple git commits

Getting a Pull Request Merged and Wrapping up

How to Contribute to an Open Source Project on GitHub

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.

[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.

Course

How to Contribute to an Open Source Project on GitHub

How to Collaborate on a Pull Request on GitHub

Share this video with your friends