Pull requests are a core part
of making a change to any GitHub repository.
Let's figure out how to use them effectively.
(smooth music)
Pull requests are a means
of submitting a change to another code base.
You can do this whether you're a core contributor,
or you're working at arm's length with a fork.
If you're not a core contributor, you can fork this project,
work on that change on your own
and send that change back as a proposal
on a pull request to the original author.
It means that making a correction becomes easier than making a complaint,
which is why GitHub has really facilitated the growth and development of Open Source.
Just make that edit, make it better,
everyone benefits.
This also applies to closed projects, corporate projects, private repos.
If you do have access to push to a repository,
you should still work on a branch and send that pull request
to get some review on your code.
This means you're going to create a branch,
start making some commits, and when you're ready to get it reviewed,
send that back to everyone else on your team in that pull request.
This means that a pull request is a conversation,
not just a one-shot submission of what's on a branch,
but rather, a little bit of dialogue and discussion,
some revision to the code, that all appears in chronological order,
and finally, an approval, or in the terrible case,
a thumbs down that says, "this does not seem like a wise change to the code base."
But in either of those two situations, the URL and the pull request lives on.
You don't have to stop talking
just because things were closed out and not accepted.
You can continue to find out why it wasn't accepted
and what changes you can make in the future
to make sure all your pull requests will be accepted.
This also serves as an educational tool
for people who join the team at a later time.
These pull requests are dialogues of what type of change
might be culturally acceptable here,
what are the expectations, requirements, formats
that people expect stuff in,
and you can save these URLs and point to them as educational tools
for these new individuals.
This means you don't have to forward on some email conversation
about how a feature came to be.
You can just point someone to a URL and they can look at it for all time.
We're also interested in the technical inputs,
not just the human ones.
A CI system, continuous integration,
like Travis, Hudson, Jenkins, Circle CI, Team City,
can all integrate with a GitHub pull request
and report the build status for this branch,
the fundamental unit of a pull request,
right in the line with that conversation.
So that means along with the conversation and the changes to code,
there's little build statuses that'll pop up to say,
"yes, all the tests have passed" or "no, we have some failing test".
It also affects the status of the Merge button
providing you a warning saying,
"wouldn't you like to have all the tests passing
and this branch be clean,
before you potentially press this Merge Pull Request button?"
So now that we have CI status integrated with the idea of human feedback,
we have holistic, human review plus technical set of tests,
but not only on the contents of the branch,
but on a predictive merge of both the branch and its destination,
so you get to see into the future
what this would be like if it was merged.
This doesn't mean that that merge is permanent.
It'll actually do that predictive merge, see how things go,
and then let you know if you did merge this in,
if you would be successful or not.
So if CI reports a good status, you have social acceptance
with a couple of thumbs up and ship its in the thread,
it's time to press the Merge Pull Request button.
Once that happens, you're also presented with the option to delete the branch,
which sounds kind of scary, but isn't a bad thing.
We don't have to really worry about closing out and deleting that branch
because all of the commits are in the destination branch.
They've been preserved,
so you can delete that branch to let people know
future development isn't happening over there.
The pull request still stays around,
in case you want the record of the discussion,
and your identity and the credit for the work that you've done
appears in the destination branch along with those merged in commits.
Thanks for watching this Git and GitHub Foundations episode
on the World renowned pull request.
Don't forget to click Subscribe on any of these channels on the side.
Or, ask us a question or leave a comment down below,
or check out any of these other educational videos
on Git and GitHub topics.