If you use Github in your development workflow, you probably use pull requests. At some point, you might need to get the code resultant of merging that pull request. Or even the code in that pull request, before being merged. If it’s the case, you have to edit your .git/config file, which might look like this:
[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true precomposeunicode = false [remote "origin"] url = git@github.com:fpalomo/test-conflicts-github.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master [branch "test"] remote = origin merge = refs/heads/test
and in the remote “origin”, you have to add the next lines:
[remote "origin"] url = git@github.com:fpalomo/test-conflicts-github.git fetch = +refs/heads/*:refs/remotes/origin/* fetch = +refs/pull/*/head:refs/remotes/origin/pr/* fetch = +refs/pull/*/merge:refs/gh-merge/remotes/origin/*
With this, you will be letting your repository know that you also want to download the remote pull requests and the merges. Now you should execute:
MacBook-Pro-de-Fernando:test2 fernando$ git fetch origin remote: Counting objects: 4, done. remote: Compressing objects: 100% (2/2), done. remote: Total 2 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (2/2), done. From github.com:fpalomo/test-conflicts-github * [new ref] refs/pull/1/head -> origin/pr/1 * [new ref] refs/pull/1/merge -> refs/gh-merge/remotes/origin/1
From this moment, you could obtain the code in the pull request number 1 with the next simple command:
MacBook-Pro-de-Fernando:test2 fernando$ git fetch origin pull/1/head:pr_1 From github.com:fpalomo/test-conflicts-github * [new ref] refs/pull/1/head -> pr_1
now, with git checkout pr_1 you would be browsing the code contained in that pull request. However, if you want to see the actual final code resultant of this merge ,which you could use to place your code in a staging server , where you could launch your acceptance tests , and perform your User Acceptance Tests, you should execute:
MacBook-Pro-de-Fernando:test2 fernando$ git fetch origin pull/1/merge:merge_1 From github.com:fpalomo/test-conflicts-github * [new ref] refs/pull/1/merge -> merge_1
And you are almost there, now:
MacBook-Pro-de-Fernando-Palomo-Garcia:test2 fernando$ git checkout merge_1 Switched to branch 'merge_1'
Yes! you have the merged code before executing that actual merge.
I hope this is useful for you as it was for me when preparing a continuous delivery workflow in one of our customers.
Thanks for the post. Have you seen any issues with doing the pr/#/merge for pull requests opened where the “head” branch is apart of the “base” repository.
I am seeing, if I open a pull request [fork] -> [main repo], I get the /merge ref. However if I [main repo] -> [main repo] I am not seeing it.
Thanks
Since I came across your alricte looking for something else and it is pretty well referenced despite its age, I’ll add my 2 cent of update :)There is an easier way to do this since version 1.7.0 of git (at least more understandable for my poor brain):1- Create the local branch from the current one1git checkout -b new_feature2- Push that branch to the remote1git push origin new_featureAt this stage your local branch is set to push to the remote but pull won’t work3- Set the upstream branch to track1git branch –set-upstream new_feature origin/new_featureNow you can both push to / pull from the remote branch4- If you need to delete the remote branch1git push origin :new_feature