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 July 6th, 2017, by Matthew Setter

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.

# Create a feature branch to contain the list of changes
git checkout -b work-missing-from-stable10

# Find the commits in master that aren’t in stable10
git log --format=%h stable10..master

# Use sed, awk etc to find the first and last from the list above

# Cherry pick the changes onto the new branch
git cherry-pick first-hash..last-hash

# Push the changes to GitHub
git push origin work-missing-from-stable10

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.

Conclusion

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.


Like That?

Don’t miss my next post. Drop your email in the box below, and get it straight to your inbox, PLUS exclusive content only available by email. No spam, and you can unsubscribe at any time.