So now we get to talk about pull requests.
This is the first of a few videos on the topic.
I'm just going to start in this video by talking about what poll requests or polls are and why we want
them or why they exist.
And then in subsequent videos we'll make our own.
Okay.
So we talked about this concept of working on branches and how that makes our life a lot easier.
But then at some point somebody needs to merge those changes in from a feature branch into some main
branch master, main, whatever, right?
We don't just stay on separate future branches forever, otherwise everyone would be working in a silo
and never merging and sharing their code, which defeats the whole collaboration thing.
So rather than just allowing a free for all merge, especially if you're at a company where the stakes
are high and you can't afford to screw up something on the main or the master branch, you have users
you've got I mean, even if if not that, if you've got hundreds of developers and somebody includes
some bad commit or something that breaks things on the main branch, at the very least, you've got
100 something developers who now have a bad version of that main branch and they have to get rid of
a commit or reset.
It's just annoying and you want to make sure that whatever you are merging in or whoever is doing the
merging has some discussion around it, has some approval.
Maybe changes are made at the request of somebody else, right?
There's some code review process involved and pull requests or peers are an integral part of that process.
So pull requests are not a Native Git feature.
They are built on top of platforms like GitHub and Bitbucket and some others.
But really most people are referring to GitHub these days, but again, not exclusive to GitHub and
100% not part of Git itself.
So pull requests allow developers to tell other team members, other collaborators that they have some
new work, that they want to be reviewed, new work that is on a branch that they want to be discussed,
accepted a.k.a, merged in or rejected.
And this facilitates discussion.
They can get feedback, they can even update the work on the same pull request.
So think of it as, Hey, everybody on my team, hundreds of people.
I have this new branch with this feature I just completed, or I think it's complete.
It's on GitHub.
I'm making this request, this pull request.
Can you take a look at it and somebody will you merge it in if it's good or will you tell me if it's
not good?
That's pretty much what a pull request is.
So we do some work locally on a feature branch like we did in the last couple of videos.
Stevie added the nav bar branch, we finished the nap bar, we push it up to GitHub instead of just
merging that directly into Master or into Main.
And a lot of companies, actually the main branch is protected.
I'll show you how to do that.
You can't just merge stuff in.
You actually have to make a pull request so that there's an opportunity to discuss and accept or reject
your changes.
Somebody makes that decision.
Maybe multiple people actually have to consent and and actually approve of your changes.
So once you make the pull request, you then have to wait for it to be approved and hopefully merged
or something.
Discussion.
It might be closed, it might be ignored, but hopefully not.
So here's an example of some diagrams.
I'm working on this feature.
I finish it, I push it up to GitHub and I want to open a pull request.
So on GitHub there's this new branch, my new feature, and you've probably seen this before, compare
and pull request.
It showed up a couple of times.
When we push branches up, that is a button.
I definitely want to click to make a pull request or I can also click it here.
There's a couple of different ways of doing it, but if I click pull request, I then have this option
to choose.
What pull request am I making?
Well, I am requesting that my branch, my new feature be merged in to Master or to main or whatever
the default or it could be any other base branch.
But typically we're talking about Master Main.
So then I need to provide some information, right?
I need to come up with a name for what my pull request is.
What's the reason for it?
What does it include?
Depending on the company and the organization, there can be some pretty strict rules for what goes
in here.
And then I can click, create, pull, request, and then I wait.
So in this hypothetical world of these slides, I have a boss and my boss is the only one who can approve
changes, who can actually merge pull requests in on GitHub.
There are different ways of configuring permissions and all of that that we can get into, but basically
my boss has to accept my pull request.
I, as just an employee, I actually don't have the ability to merge directly into master on GitHub.
I'm supposed to make a pull request so my boss finds some issues and she actually leaves some feedback.
She asked me to make some changes, ping me when it's ready.
I can notify people or I can mention people in comments.
I can attach files.
She can even just close this out, by the way.
Just close it without comment.
No, it's a bit of a blunt way of saying no.
Or she can just leave the comments.
So then I can respond.
We can have a conversation about it, right?
I can say, okay, sounds good.
I'll get to work on blah, blah, blah, blah, blah.
Or I can say something like, Hmm, are you sure you really want me to do that?
What's the motivation?
Or I mean, I'm not sure I agree with that.
What do you think, other developer?
And then I can bring somebody else in and we can have a full discussion here as a team.
I can even make more changes if she requests them, but then eventually, hopefully my boss decides
things are good to go.
It's time to merge those changes in.
So if she accepts my request she can then go and click merge, pull, request and merge my changes.
Or whoever is in charge of doing the merging, merge my branch in to the main branch, the branch I
was requesting.
And then we're good to go.
So she'll click that button and then I'll demonstrate this for real, not just with slides.
Then she can make the merge commit message directly on GitHub.
So this is just a mechanism for merging changes in from a feature branch into some other branch where
instead of just going for it, we have this process, we can have conversations, we can chat with each
other, we can make updates, request things, we can reject a suggestion or a pull request or we can
accept it.
But if my pull request is accepted, the end result is still just.
My branch is merged into another branch.
It's just a slower, longer process that it's more transparent and more controlled, I guess, for merging.
So that's an intro to the concept of pull requests.
I'll wrap up by showing you that if we look at any popular repository on GitHub, there's going to be
a section for pull.
Requests like this is React, a very popular repository, lots of contributors.
Those contributors don't just directly push changes up.
They don't even have permission to directly push changes to any of the branches here.
There's another way of making pull requests.
We're going to talk about involving something called the fork and clone workflow.
That will be coming up in a little bit.
It's a common pattern to contribute to open source projects where you're not an actual collaborator,
you don't have permission to push anyway.
We'll get there.
But if we go to pull requests, we can see quite a few of them here.
And again, there's a lot of structure and patterns that have to be followed when you're creating a
pull request for a big open source project.
So they all follow particular naming conventions.
They all have these different tags.
But you can see here's one somebody wants to merge, one commit into master from their feature branch.
Notice the name of this feature branch.
Well, this is not a great one actually from depend, but if I find another one, how about this one
here?
So this is a pull request from the branch.
Rick and Hanlon to.
And Loney.
I don't know.
RH add effect.
Warren test.
That's the feature branch.
Whatever he did on this branch.
He wants to merge it into master and then we see some information about what his pull request includes.
He wants to add a test so we can see under commits.
Here's the commit.
We can view that commit what's included, what's new.
So some new code here and then there's a discussion around it.
So this person said, please, they should probably throw an error like how?
Blah, blah, blah, blah, blah.
So there's a conversation, in other words, and this one is still open meeting.
It has not been closed or rejected, but it also has not been merged.
Oh, and there's a lot more conversation here around this PR and that's kind of a good place to end,
just to show you an example.
So these larger projects have tons of pull requests.
Sometimes it can take a little while to get yours.
If it's not super important, if it's not a critical feature you're working on, it can take a little
while to get noticed, depending on the resources available to the project maintainers.
Anyway, that's a basic idea of a pull request.
I'll show you the workflow in the next video.