An "old, but gold" trick to easily fetch Pull Requests from Github A dark wallpaper with the Github logo's silhouette in the center There's a practice widely used in popular projects hosted on for receiving contributions efficiently. The contributor creates a small branch that represents a single feature, and when that branch is pushed to the contributor's fork they create a Pull Request. I have elaborated on the best practices of how to do this in a previous post called Open Source Github One Pull Request. One Concern. As from the time of this writing, jQuery uses this model extensively among their contributors. They document the model in their guideline and use it as a requirement for new contributions. They have been using it for years. Commits and Pull Requests A common practice in Open Source projects is to request for a contributor to fork the project, create a temporary branch and create a Pull Request from that branch that represents a . single concern There are companies that also use this model for managing their development. Pull Requests allow developers to integrate their changes frequently, which reduces the chances for code conflict and make it possible to spot bugs early. This is early feedback, which is one of the core principles of . Continuous Integration There's one trick, though, that we can use to manage Pull Requests. When using Github, everyone that have permissions to merge Pull requests to the master branch have 2 options: Use the the commits to the master branch. Github Pull Request UI to merge Use in the command line to add the reference to the Pull Request branch as a remote locally ( ), fetch the Pull Request branch from that remote and then merge the commits to the master branch. git git remote add <contributor's fork url> is the most common and the easiest one. Whoever has permissions can go to the Pull Request page on Github and click the "merge" button. The first option is most commonly used when who is merging the Pull Request want to have total control over the commits that are landed on master. Why is that? Well, there are workflows that may need to commit on master with git information that Github don’t set through their Pull Request Web UI. Linus and that's why he doesn’t even accept Github Pull Requests in the Linux Kernel. The second option have complained about this in the past The issue with the second option is that you need to add a remote for every Pull Request in order to commit on master. Many Pull Requests can have different contributors with different forks. Adding all of them can become messy because you will eventually have tons of remotes in our local copy of the project. published an 4 years ago that allow someone to download all Pull Requests from a repository locally with a single command. Bert Belder interesting trick git fetch The trick is to add the line below to the file that is located from the root of the project you want to change: .git/config fetch = +refs/pull/*/head:refs/remotes/origin/pr/* The part that says can be different. It just represents the name of the remote that has a reference to the repository you want to fetch the Pull Requests from. It's the default name for the remote that git creates when we use the command . origin git clone <path to the repository> When running the command with this trick, git will fetch all Pull Requests that have been opened against that remote: git fetch The output of the "git fetch" command when the Pull Request fetching technique is applied. It's fetching the refs from a copy of the project. js-cookie Notice the part, that's when the Pull Requests are fetched from the remote. They will be available to be checked out using . [new ref] refs/pull/280/head -> origin/pr/280 git checkout origin/pr/280 Ok, now can you push the changes to a Pull Request using the same command line trick? According to the , you can't. Github doesn’t allow pushing to a hidden ref: Github documentation The remote namespace is refs/pull/ read-only — Github's " " documentation Checking out pull requests locally Any attempt to push to the ref will present the following error: ! [remote rejected] HEAD -> refs/pull/1/head (deny updating a hidden ref) The only way to update a Pull Request is adding a new remote that has a reference to the fork of the contributor who created it. If you have permissions to write in their fork, you can push any changes to the Pull Request branch in their remote and it will be updated on the Github Pull Request Web UI automatically. It's impossible to change a Pull Request using the multiple Pull Requests fetching trick because Github makes hidden refs as read-only This Pull Request fetching trick will make your workflow more convenient when working with Pull Requests. It's one of those things that are very simple and still yields a lot of benefits depending on your workflow. I have been using this for a long time in projects using the second option. What about you? Thanks for reading. If you have some feedback, reach out to me on , or . Twitter Facebook Github

Facebook

Fetch

ThoughtWorks

How to Handle Github Pull Requests Like A Boss

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Test Is As Good As Its Ability To Fail When It Needs To

10 GitHub Repositories to Follow

3 Easy Steps to Change Main Git Branch on Heroku

28 Stories To Learn About Markdown

194 Stories To Learn About Git

A Test Is As Good As Its Ability To Fail When It Needs To

10 GitHub Repositories to Follow

3 Easy Steps to Change Main Git Branch on Heroku

28 Stories To Learn About Markdown

194 Stories To Learn About Git

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps