Pull Requests • GitHub & Git Foundations

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.