When do GitHub pull requests get closed automatically?

This is Ohara(@kory1202), I am currently working as an engineer for the server side at LINE. The way we handle our code on Git is this; we create pull requests with the master branch as the base branch. We’ve seen pull requests getting automatically closed when merging them, but weren’t aware the precise condition for such automatic closings. We checked out the information on GitHub Help > Closing a pull request, but weren’t able to get the answer we wanted. So we decided look into it, and here is the result of our investigation.

What is automatic closing?

Automatic closing is the term we use to describe a pull request (PR) getting automatically closed without any manipulation on GitHub to close it manually. You will get the idea better with an example. Suppose we have commits in the branches shown below.

And suppose we have two pull requests as follows:

  • master ←PR– develop (This notation implies a pull request with the head branch as ‘develop’ and the base branch as ‘master’)
  • master ←PR– feature (This notation implies a pull request with the head branch as ‘feature’ and the base branch as ‘master’)

On GitHub, when you merge a pull request from the develop branch to the master branch, the pull request from the feature branch gets automatically closed. This closing is what I’d like to go over with you today.

Questions and questions

As I mentioned earlier, I was aware that some pull requests were automatically closed, but there were many areas I wasn’t so sure about:

  • What triggers automatic closing of pull requests? What affect does base branch have?
  • Suppose we have master ←PR– develop ←PR– feature; in English, we have a pull request from the feature branch to the develop branch, and another one from develop to master. If we merge master ←PR– develop before merging develop ←PR– feature, does develop ←PR– feature get closed automatically?
  • If a hotfix is applied to the master branch, then do we need to synchronize the develop branch and other feature branches to the master branch?
  • Can something trigger a pull request to be merged and closed automatically before reviewing?
  • Can an unapproved pull request get closed? If so, what triggers it?

The answers to these questions are at the end of this post, so feel free to skip what’s in between. If you wish to get the details, read on.

Let’s look into it

How you manage and operate Git — which branch to use as the base branch for pull requests, when to merge and so on — varies, but a common practice seems to be having three branches, one for the real environment, one for QA, and one for others. Based on this assumption, let’s suppose we have the following three branches and take a close look at the affects of the base branch of a pull request, merging and automatic closing.

  • master branch: Real environment
  • develop branch: QA environment
  • feature branch: Miscellaneous

We focused on the role of the base branch affecting automatic closing. In other words, how would setting the base to master or develop change things.

Investigation 1. Correlation between pull request base branch and automatic closing

First, let’s see if there is a correlation between the base branch and automatic closing. The first case we’ll look has only one feature branch. The second is when there are two or more feature branches that have dependency in between.

Only one feature branch

Let’s consider this case. We have only one feature branch and the following two pull requests:

master ← PR– feature

We have a pull request from a feature branch to the master branch. And as you can see from the diagram below, we have another pull request, headed to the master branch from the develop branch.

To apply the changes in the feature and develop branches to the master branch, we create two pull requests and perform the following tasks 

  1. Merge locally the feature branch to the develop branch and then push the develop branch to the remote repository. 
  2. On GitHub, merge the develop branch to the master branch (this results in an automatic closing!)

At the second step, the pull request created from the feature branch gets closed automatically.

develop ← PR– feature

Similar to the case we’ve just looked at, we have only one feature branch and have two pull requests. The major difference is this; unlike both of the pull requests having the master branch as the base branch, here we have one pull request from the feature branch to the develop branch and the other from the develop branch to the master branch.

Consider the following two scenarios:

Scenario 1

  1. On GitHub, merge the feature branch to the develop branch
  2. On GitHub, merge the develop branch to the master branch

Scenario 2

  1. Merge locally the feature branch to the develop branch and then push the develop branch to the remote repository (this results in an automatic closing!)
  2. On GitHub, merge the develop branch to the master branch.

The second scenario is the case we’ve looked at(#feature-to-master), but auto closing occurs in the first step, not the second; the pull request from the feature branch gets closed automatically. 

Now, what would happen if we merge master ←PR– develop right away, without merging the pull request from the feature branch to the develop branch? Will develop ←PR– feature get closed automatically? Here is the result:

  • The pull request from the feature branch is not closed.
  • If you merge develop ←PR– feature, you can create a pull request from the develop branch again.
  • The develop branch becomes undeletable on GitHub unless you delete the feature branch or change the base branch of the pull request from the feature branch to something other than the develop branch. (However, if you force-delete the develop branch with the command git push --delete origin develop, the pull request from the feature branch is closed automatically.)

Two or more feature branches with dependency

Before we get into the details, what does it mean by branches with dependency? Suppose we are adding a feature called hoge. Then we’ll make a branch for the new feature called add_hoge and another for improvements named update_hoge

While a pull request from the add_hoge branch is being reviewed, someone could create a pull request from the update_hoge branch. Or perhaps the size of the new feature could be so big, you might want to breakdown pull requests, for easier review.

Since the update_hoge branch is based on the add_hoge branch, you’d want to send a pull request from the update_hoge branch to the add_hoge branch. Let’s see if auto closing occurs.

master ← PR –  add_hoge

As illustrated in the following diagram, we have three pull requests. There are three ways to apply the changes in the add_hoge and update_hoge branches to the develop branch and then merge the develop branch to the master branch.

Option 1

  1. On GitHub, merge the update_hoge branch to the add_hoge branch.
  2. Merge the add_hoge branch to the develop branch locally.
  3. On GitHub, merge the develop branch to the master branch (This results in an automatic closing of the add_hoge branch!)

Option 2

  1. Merge locally both the add_hoge and update_hoge branches to the develop branch.
  2. On GitHub, change the base branch of the pull request from the update_hoge to the master branch.
  3. On GitHub, merge the develop branch to the master branch (This results in automatic closing of both the add_hoge and update_hoge branches)

Option 3

  1. Merge locally the add_hoge and update_hoge branches to the develop branch.
  2. On GitHub, merge the develop branch to the master branch. (This results in automatically closing the pull request from the add_hoge branch, but not the one from the update_hoge branch.)
  3. Manually close the pull request from the update_hoge branch.

Now, option 2 and 3 are for when you don’t want to merge the update_hoge branch to the add_hoge branch perhaps because the add_hoge is still being reviewed, but wish to merge it to the develop branch for QA. Yes, I know, this is a ridiculous case; we shouldn’t be merging branches to the develop branch unless reviewing is complete, but bear it with me, we are doing this only for this post.

What I found out is that with option 2 and 3, the pull requests from the update_hoge branch are not closed when they are merged to the master branch, because the base branch of the pull requests are not the master branch.

develop ← PR– add_hoge

Just as we’ve looked at our previous case, we have three pull requests. 

We have three options to merge the update_hoge and add_hoge branches to the develop branch and to the master branch.

Option 1

  1. On GitHub, merge the pull request from the update_hoge branch to the add_hoge branch.
  2. On GitHub, merge the pull request from the add_hoge branch to the develop branch.
  3. On GitHub, merge the pull request from the develop branch to the master branch.

Option 2

  1. On GitHub, merge the pull request from the add_hoge branch to the develop branch.
  2. On GitHub, change the base branch of the pull request from the update_hoge branch to the develop branch.
  3. On GitHub, merge the pull request from the update_hoge branch to the develop branch.
  4. On GitHub, merge the pull request from the develop branch to the master branch.

Option 3

  1. Merge locally the update_hoge branch to the develop branch
    • The pull request from the add_hoge branch is closed automatically, but not the one from the update_hoge branch. 
    • The base branch of the pull request (from branch update_hoge) cannot be changed to the develop branch. An error occurs with the message, “There are no new commits between base branch ‘develop’ and head branch ‘update_hoge'”.
  2. Manually close the pull request from the update_hoge branch.

Investigation 2. Handling hotfix merges on the master

To cut to the chase, when a hotfix is merged on the master branch, you don’t need to to merge the master branch back to the develop branch or a feature branch. Even if changes are made in the base branch, as long as there is no conflict, a pull request to the base branch would be closed automatically. However, not having to merge the master branch is only in regards to automatic closing. In practice, we’d want to know if our changes would work when they are merged to the master branch, so we’d merge the master branch to the develop and the feature branches.

Now, the following is my investigation on how the base branch — master or develop — affects a pull request created from a feature branch.

master ← PR–  feature

Here is a picture illustrating a case of merging a feature branch to the master. Had we merged the master branch to the feature branch, we need to merge the feature branch to the develop branch again. This is because GitHub would automatically close the pull request from the feature branch (master ←PR– feature) when the pull request from the develop branch is merged to the master branch.

How GitHub finds a pull request to close is implemented in the same way as the git branch --merged command. If the master branch cannot find the commit pointed by the head of the feature branch, the pull request from the feature branch is not closed automatically. I’ve made an enquiry on the GitHub forum if this understanding was right, and I was confirmed (Although I’ve enquired at a wrong place, the community manager answered me kindly.)

 develop ← PR–  feature

This diagram illustrates the case of having a hotfix on the master branch. This case is simple. If there is a conflict between branches feature and master, all you got to do is merge the master branch to the feature branch. This would resolve conflicts. After confirming that the content of the feature branch works fine, you would merge the feature branch to the develop branch on GitHub. If you locally merge the feature branch to the develop branch, the pull request from the feature branch will be closed automatically.

Conclusion

Let me conclude my post by answering the questions(#questions) I had earlier.

What triggers automatic closing of pull requests?

A pull request is closed automatically in the following cases:

  • When a change is applied on the base branch.
    • For this to happen, the head of the head branch must have been merged to the base branch.
    • Even if you merge locally and push, when you apply the change, the pull request gets closed automatically.
  • When the base branch is deleted, pull requests to the base are closed automatically.

Here are the cases when a pull request is not closed automatically:

  • A pull request from the base branch getting closed does not automatically close the pull request that is headed to the base branch. 
  • A pull request that has the base branch set to something other than the master is not automatically closed even if the pull request is merged to the master branch.
  • Pull requests that have the base branch set to something other than the master branch are not automatically closed when they are merged to the master branch.

Suppose we have master ←PR– develop ←PR– feature. If we merge the develop branch to the master branch before merging the pull request from a feature branch, does the feature branch get closed automatically?

No, it does not.

When a hotfix is applied to the master branch, do we need to synchronize the develop branch and other feature branches with the master branch?

Only when there is a conflict. If you merge the master branch to a feature branch, then you need to merge the feature branch to the develop branch.

Can something trigger a pull request to be merged and closed without intention, before reviewing?

No, and boy, am I relieved.

Can an unapproved pull request be closed? If it can, what triggers it?

Suppose we have develop ←PR- feature and if you locally merge a feature branch to the develop branch for QA, then the pull request from the feature branch gets closed automatically. However, the same operation with master ←PR– feature does not close the pull request. I’ve had an experience of running two separate repositories at the same time, one with the maser branch and one with the develop branch as the base branch, and having different base branches, I accidentally caused an automatic closing. So be aware of your base branch.

Closing

So, we’ve looked at auto closing of pull requests on GitHub. I hope this was helpful to those of you who were wondering when and why your pull requests were and were not closed automatically. A topic I considered including here was pull request accidents, but lately what I’ve experienced is only of pull requests getting automatically closed unexpectedly. Perhaps GitHub has taken measures to prevent such accidents. If you are aware of any patterns that cause accidental result, please let me know. You can reach me at my twitter account here.

Related Post