At Devmountain, we know that managing a large-scale group project can be difficult. At any given time, there could be a number of people making changes to different parts of the code. Sure, you can communicate by email or in person, but those methods have the potential to fail.
Email threads can be convoluted and hard-to-follow. People can forget things. All of these struggles are multiplied when an open-source project needs to be worked on and the people you’re working with are strangers.
So, what do you do to fix the problem? Well, this is where pull requests come in.
A pull request is designed to help keep changes separate from the main project, increase internal (and potentially external) communication, and allow for more effective debugging. Pretty magical, right? It’s so cool that GitHub uses these in the development of its site. But, what is a pull request in GitHub? And, how can you utilize it?
First of all, pull requests only work when a project is a single, public repository. In order to make changes to a single repository, users create branches (separate portions of code) to test additions or changes. Once a branch has been reviewed and approved, it can be merged into the remainder of the code using a distributed version control system (DVCS) to submit the pull requests.
In order to keep programming in line and increase the potential for effective communication, pull requests work hand-in-hand with branching or forked workflows. A pull request, at its most basic, sends an alert to a project maintainer. Developers only need access to read the repository to send a pull request, though to make changes to be merged into the public repository, they will need to request write access.
Once they have access, developers can create a topic branch, giving themselves access to the code they want to change. Keep in mind that none of these amendments will be able to reach the source code itself until it is approved and merged upstream into the original code.
Once a pull request is sent, other members can look over your code. The pull request can be marked for review, and people can add questions or comments to it. Eventually, a project maintainer will decide whether or not the pull request should merge with the rest of the code.
Now, although GitHub gets along just fine with their Git software, there is other third-party software available to help you and your team make the most out of Git.
For example, Bitbucket is a product that adds to what you can do with your pull requests.
With Bitbucket, users take copies of code and place them in their own Bitbucket repository. This means developers can send pull requests to individual repositories, as well as the original.
Now that you know what a pull request is and how it works, the next question is how do you do it. First, it’s important to note that there is a difference between a pull request and a draft pull request. A draft pull request cannot be reviewed or merged, so if you’re ready to roll, make sure you turn your draft into an official pull request by marking it ready to review.
The good news is, on GitHub this process is very easy. There’s even a button that reads “Pull Request.” Once you’ve selected a request, you’ll need to select the branch where you want to merge your work. And just like that, you’ve created a pull request!
GitHub also tries to make merging your pull request as painless as possible by providing a “merge pull request” button at the bottom of the page. Granted, this function will only work if GitHub doesn’t find any glaring merge conflicts between your pull request and the source text. If you can’t use the merge pull request button, you will have to merge the two manually.
If you’re worried about merge conflicts, try merging your code to a local copy of the source code first. This will let you test whether or not there will be problems without struggling with the original code. Once you’ve run your tests and made any fixes, it should be much easier to merge your pull request.
Pull requests will allow you to get feedback on your work and allow you to give feedback to others. Furthermore, with third-party systems available to add to the functions of basic pull requests, the sky’s pretty much the limit for what you can accomplish.
Caught the coding bug? You could learn to code at Devmountain in thirteen weeks.