If you have ever attended a meeting at work, then you can understand pull requests.
When you join a software development team or open source project for the first time, you will probably use a “pull request” to allow your code to get merged into the project.
When I first learned about pull requests, I was slightly confused. I already knew about GET and POST requests from HTTP,
But, in those cases, GET is the type of request. There are a limited number of types of HTTP requests, and GET and POST are two of them. In plain English, it is saying, “I request this specific server via the GET method.”
But, in a pull request, a “pull” is NOT a type of request in Git (or at least, not formally). Instead, it is actually a request for another team member to git pull your code. In plain English, it is saying “I request that you git pull this code in order to review it.”
A GET request should receive a response in milliseconds. A pull request could take anywhere from minutes to weeks to review.
So, I wanted to find a simpler way to understand a pull request. In a previous post, I used the analogy of building a new car with a team to teach the basics of Git. You can check out that article if you want, but for the sake of this article, just imagine that you are building a new car with teammates from a variety of backgrounds-design, engineering, manufacturing etc.
Each person needs to present their recommendations to the team so they can be reviewed and accepted or rejected. You can’t have a system that allows one teammate to accidentally contribute work that causes other parts of this new car model to fail!
Here’s what needs to happen before a pull request.
Prepping For A Pull Request
Before you submit your pull request, you need to prepare all your proposed changes to be reviewed by others.
Imagine that you are on the car development team that was introduced above. You would not be making changes to the CAD files and prototypes that the rest of the team was using! Instead, you would need to copy these to your local computer so that you could make changes without disturbing anyone else’s work.
Then, you would need to summarize all your changes in a Powerpoint presentation, and show them to the rest of your team to get approval.
This process of creating a presentation is just like submitting a pull request! Before a pull request, you must first create a new branch that you can modify without interrupting your team.
Then, you must git push all your commits to the branch so that they become visible to others.
Finally, you would create a pull request to tell teammates that they need to review those changes before they can be merged with the master branch. A pull request tells teammates that they must git pull your pushed changes in order to review them.
In the example above, there are three branches: master, branch1 and branch2. You are making changes to branch2 locally on your computer via commits, so you git push them so they can be included in a pull request.
git push (reponame) branch2
Then, create a pull request in Github to indicate that you are ready to merge those changes. This will notify all appropriate members of your team that they need to git pull your changes to review them.
In both meetings and pull requests, all the decision-makers get notified synchronously, or all at once. But, they can give their approval asynchronously, or at their own pace.
Approving The Pull Request
After you have pushed changes and submitted a pull request, the pre-determined reviewers must pull your branch and then approve it. Once the correct people have approved, it can then be merged into the main branch (master, in this case).
Let’s return to our meeting example. The “pull request” is your presentation about changes that should be made to the new car.
After you finish the presentation, all attendees must review your work and approve before it can be used in the main design for the new car. Then, once it is merged with the new design, all other team members will work with your changes in their own work.
Here’s what that looks like in code:
Once three team members have approved the pull request, branch2 can be merged into master.
Interested In More Visual Tutorials?
If you would like to read more visual tutorials about HTML, CSS and JavaScript, check out the main CodeAnalogies site for 50+ tutorials.
Or, sign up here to get the latest.
