Merging 2 pull requests in case of linear history.

Let’s suppose that Alice and Bob work together on some project. Each of them has local repository and they share single remote repository on GitHub. Local tree of Alice looks as follows:

* 3333333 (origin/Bob_pull_request_2)
* 2222222 (origin/Bob_pull_request_1)
* 1111111 (HEAD -> develop, origin/develop)

Bob has create 2 pull requests on GitHub. Alice starts with reviewing the first one and decides to merge it. She doesn’t want to change the history of the tree so she executes:

git merge origin/Bob_pull_request_1
git push origin develop
git push --delete origin Bob_pull_request_1

As a result the tree looks like this:

* 3333333 (origin/Bob_pull_request_2)
* 2222222 (HEAD -> develop, origin/develop)
* 1111111

Now, if Alice goes to _Bob_pull_request_2 _on GitHub, navigates to Files changed she can still see all files that has changed betwenn commit 1111111 and 3333333.

Why GitHub doesn’t see that _Bob_pull_request_1 and Bob_pull_request_2 _share the same commit 2222222.

After merging _Bob_pull_request_1 _GitHub still treats _Bob_pull_request_2 _as it should be merged to commit 1111111 instead of branch develop.

Is this expected behavior ?

Is the above workflow of Alice and Bob ok?


Yes, this is expected behavior. Yes, this workflow is fine. The merge should work just fine whether executed through the Git command line or through the GitHub web UI.

Let us know if you have any other questions.