Use GitHub to Quickly Compare Two Branches and Create a PR of the Changes

Use GitHub to Quickly Compare Two Branches and Create a PR of the Changes

If you need to quickly create a PR of the changes between two branches, GitHub is the quickest and most pragmatic choice. Here’s why.

As part of my work as documentation lead at ownCloud I have to ensure that the documentation reflects — as much as possible — the various ownCloud releases. To do that, we keep the documentation in a git repository on GitHub and work with it as follows:

  • master is the source of all truth, containing all of the latest changes.
  • Each change is made on a feature branch forked from master and merged back to master, when discussed and approved.
  • For every ownCloud release there’s an equivalent branch. For example: “stable8” contains the documentation for ownCloud version 8 and so on.

However, that way of working has the potential for feature branches merged to master to not be merged to an applicable, “stable”, branch. And so it was recently with the latest version branch, “stable10”; a number of PRs had been merged to master, but were missing from “stable10”. Given that, I then needed to find out which ones.

To do that, my first thought was to find out which feature branches merged to master had not yet been merged to “stable10”; that way, I could merge changes in logical batches. I thought I’d be able to get a list of them, then merge them one by one. Whether that’s the right approach or not I’m not sure. But it made sense.

The trouble is, my knowledge of git isn’t at the advanced level. I experimented with git log, branch, cherry, reflog, and name-rev, trying to find a way to build the relevant branch list, seeming to get ever closer, but never quite getting there.

GitHub to the Rescue

After hitting a, proverbial, brick wall, I thought I’d try and find further information via GitHub that could help aid in my search. While there, I saw the “Compare” link, and was intrigued; maybe this would be a simpler solution.

GitHub’s branch compare functionality.

Clicking it, it showed me (as you can see in the image below) that there were no changes in master that weren’t already in “stable10”, go figure. But, by switching the comparison around it showed me 131 commits across 226 files in master that weren’t in “stable10”.

Using GitHub to create a PR of commits not merged to a given branch.

It also offered to create a pull request based on those changes. Given that I felt I was starting to waste time looking for something that I didn’t know how to solve, I went with creating the PR.

For what it’s worth, I think that I could have done this manually, using the following commands.


HEAD=( git rev-parse HEAD )

# Find the merge commits on the FROM branch that aren’t on the TO branch
BRANCH_DIFF=( git log --cherry-pick --format="%h" --merges --left-only $FROM_BRANCH...$TO_BRANCH )
#COMMIT_RANGE=( $BRANCH_DIFF | (head -n1 && tail -n1) | xargs -n 2 | awk '{ print $2"~1 "$1 }' )

# Find the starting commit

# Find the ending commit
COMMIT_TO=( $BRANCH_DIFF | head -n1 )


# Create a temporary branch to manage the changes
git checkout -b $TEMP_BRANCH_NAME

# Copy the merge commits from one branch to the other
git rebase --onto $HEAD $COMMIT_FROM~1 $COMMIT_TO

# Replaying them

# Push the branch

# Start the creation of a PR of the current branch into stable10
# You can find the backport command at
git-backport $TO_BRANCH

But I’d then still have to create a PR, which I could have done using a couple of mouse clicks on GitHub anyway. So I did it directly on GitHub, as it seemed like the most pragmatic approach.

Is it the Right Solution?

While not my intended original solution, doing so did solve the need that I had, helping me ensure all the changes in master could be merged into “stable10”. This was an unexpected way of solving the challenge that I faced; but a solution all the same.

But while I’m happy that it solves my initial problem, I’m not sure that it’s the right solution to use, at least not over the longer term. What’s more, I’m not honestly sure if it’s possible to get a list of branches from a list of commits, or if doing so is the most efficient solution.

Furthermore, I’m questioning the approach that we’re currently using at ownCloud. From a logical, efficiency perspective, is it the right approach to take? Or should the latest build of the documentation always come from master with only previous releases being built from specific “stable” branches (or tags)?

I’m thinking that this approach has the advantage that new feature branches will be automatically added to the current release. Given that there’s no need to specifically additionally merge them, then there’s no possibility that they can be overlooked.


Am I wrong? Am I overthinking the whole thing? Or am I right? Is there a way of building a list of branches from a list of commits? I’d love to know what you think.

You might also be interested in these tutorials too...

How to Get GitHub-like Diff Support in Git on the Command-Line
Thu, Aug 24, 2017

How to Get GitHub-like Diff Support in Git on the Command-Line

If you use Git as your VCS (version control system), you’ll know that it has excellent diff support on the command line. However, even as good as it is, it still leaves a bit to be desired — at least when compared with tools such as GitHub.

Mon, Oct 16, 2017

Easy Git Interaction with OhMyZsh and Git Extras

Git is known to be incredibly terse, though it has improved in recent years. What’s more, there’s a plethora of commands that you need to remember. So, why not learn about OhMyZsh and Git Extras and make your life with Git easier!

Fix a Commit History With Git Interactive Rebase
Thu, Nov 28, 2019

Fix a Commit History With Git Interactive Rebase

Git interactive rebase is a powerful tool that can help you fix up your commit history to make it more meaningful, professional, and maintainable. In this post, I step through what it is, how it works, and when you should — and shouldn’t — use it.

4 Git Command-Line Tips for Greater Productivity
Thu, May 23, 2019

4 Git Command-Line Tips for Greater Productivity

Git, despite still being a bit terse, is extremely powerful version control software. However, because it’s so powerful, it takes time to learn. In this post, I’m going to show you four small techniques to help you use it more effectively.

Want more tutorials like this?

If so, enter your email address in the field below and click subscribe.

You can unsubscribe at any time by clicking the link in the footer of the emails you'll receive. Here's my privacy policy, if you'd like to know more. I use Mailchimp to send emails. You can learn more about their privacy practices here.

Join the discussion

comments powered by Disqus