I've seen a lot of posts about this one but not exactly in the same situation.

I made a repository here with my example.

1. I created an empty repo and the "develop" branch.
2. I created a file with lorem ipsum ("first commit").
3. I replace the file content with Asimov information ("second commit").
4. I replace the file content with Dan Simmons information ("third commit").
5. I created a PR between "develop" and "master" and I used the "rebase and merge" mode.

Everything is fine.

6. (Still on "develop") I replace the file content with Frank Herbert information ("fourth commit").
7. I created a PR between "develop" and "master" and I got a conflict issue.

In the second PR you still see the "second" and "third" commits even if they were already in the previous PR.

According to the second PR changes the file contains lorem ipsum (which is wrong the file on "master" is about Dan Simmons) and will be updated with Frank Herbert (which is correct).

I understand the PR "rebase and merge" is not a "real" rebase. It's a copy of each commit (more like a cherry pick actually). But isn't Github able to handle it in a more correct way? Or is my understanding wrong?

Are we not supposed to be able to do PR in "rebase and merge" mode between the same branches multiple time?

CodePudding user response：

If the branch (develop) is left as is, then the original revisions that were merged are not really merged.... if develop is supposed to be long lived (as is the case as you are using it for multiple PRs) then rewriting history (by rebasing or squashing) is not an option.

Suppose you had this:

A <- B <- C <- (develop)
^
 \- (master)

When you merged, you got this:

A <- B <- C <- (develop)
^
 \- B' <- C' <- (master)

Notice how develop did not move. If you add a new revision in develop:

A <- B <- C <- D <- (develop)
^
 \- B' <- C' <- (master

And if you ask to merge, git will need to consider changes from A, not from C or C'