Let's visualize your scenario:
o---o (main) \ A---B (A) \ C---D (B)
In Git, a branch is simply a reference to the latest of a sequence of commits. What commits are in a branch depends on which branches you're comparing:
- If you compare
A with main, then A has commits A and B which main doesn't have. - If you compare
B with A, then B has commits C and D which main doesn't have. - If you compare
B with main, then B has commits A, B, C and D which main doesn't have.
Now, if branch A were to be merged into main, then main would also have commits A and B. This means that if you compare branch B with main after the merge, then B would have commits C and D that aren't in main:
o---o-------M (main) \ / A---B (A) \ C---D (B) <-- these commits aren't in 'main'
The fact that GitHub is showing you commits from branch A when you do a pull request from branch B to main makes me think that branch A was rewritten (possibly rebased) after you created branch B:
o---o---o--------M (main) \ \ / \ A'---B' (A) <-- rebased commits in branch 'A' \ A---B---C---D (B) <-- branch 'B' still has the old commits
If this is indeed the case, the solution is simply to rebase branch B on top of main and update the pull request:
o---o---o--------M (main) \ / \ A'---B' \ ^ \ (A) C---D (B)
Git will notice that the changes from commits A and B are already in main thanks to commits A' and B' and will therefore only show you commits C and D when you compare branch B to main.
mainshould be enough I tink, but not sure to understand your point