Chained branching merging strategy

Git (emphasis required here, because you are probably using more than just Git itself) doesn't have a concept of a "base branch".

When you use a web interface like those on GitHub or Bitbucket to create a "pull request", it's the web interface that chooses the upstream's branch name against which to suggest the pull request. Git itself has no idea that you will make a pull request.¹ All Git knows and cares about are the commits, usually by hash ID.

When you run git merge, you choose two commits, usually two branch tips. You choose one by running git checkout, typically git checkout <somebranch>. That commit becomes your current commit. This is the commit that Git calls local or --ours; I generally call it L for left, local, or --ours. (Note that if you don't run git checkout just before git merge, whatever you have checked out right now remains your current commit, and you are therefore choosing that as your L commit.)

You then run git merge <name-or-hash-id>. Git translates the name, if you give it one, to a commit hash ID. This is how you choose the other commit, which Git sometimes calls the remote or other or --theirs commit, and I call R.

Git uses the L and R commit hash IDs, plus all the other commits in the repository, to find a merge base commit hash ID. This merge base commit is, in short, the "nearest" commit at which the two branches "come back together". The commit that Git will find here depends on the topology of the existing commit graph.

If Git is able to do the merge on its own, Git makes a new commit holding the merge result. The new commit has two parents, instead of just one: the first parent is the commit that was L at the time you ran git merge, and the second is the commit that was R. The new commit goes on the current branch, so that the current branch name—the one you have checked out—now points to the new merge commit.

The graph you drew above is hard for me to interpret: I cannot tell, from your drawing, which commits are reachable from which branch-tip commits, or for that matter, which commits are the branch tips in the first place. In particular you have drawn two commits that appear to be merge commits, but I do not know whether earlier (ancestor) commits are on the left or the right. Moreover, your text describes making one merge, not two. Using the assumption that earlier commits are towards the left—that time flows left-to-right, as it were—here is how I might draw most of this graph in text:

 o--o o--o <-- branch-B / \ / | __---o <-- branch-A |/ ...--o <-- master 

Note, however, that this graph has only one merge commit, which in this case is the commit to which the name branch-A points. The name branch-B points to the right-most commit on the top line.

In this particular example, branch-B contains every commit drawn in the graph, while branch-A contains all but the two most recent commits, and master contains only the commits on the bottom line plus any earlier commits leading up to that point. The merge base of the tip commit of branch-B (commit L) and the tip commit of master (commit R) would be the tip commit of master, i.e., commit R itself. Running git merge while on branch branch-B would therefore choose that as the merge base. The merge would be trivial to make (but in fact refused) as there would be no merge conflicts.² So that's clearly not what you are doing, and clearly not the correct graph.

Without the correct graph, it's impossible to say what Git chose as the merge base. But if you did get a merge conflict, it is because when comparing the merge base commit to commit L, Git saw one change to some line of some file, and then when comparing the merge base commit to commit R, Git saw a different change to the same line of the same file. Git was unable to choose between these two changes, so it stopped with a merge conflict, leaving the work-tree version of the file with both changes applied. It is now up to you to resolve this conflict (and any other conflicts), git add the correct merge result, and run git merge --continue to finish the merge; or run git merge --abort to stop the merge and put things back to the way they were before Git attempted the merge.

¹While they are related, don't confuse these externally-provided web interfaces with the git request-pull command-line command. That one is built in to Git, but it requires that you, not Git, choose the <start> commit. When GitHub makes the choice for you, they are using information not available to Git itself. Specifically, GitHub knows—has recorded for itself, in a location it effectively keeps secret from Git—which upstream project you used when you clicked the GitHub "fork" button. They (GitHub) also control the Git repository for that upstream project, so they can peek inside it and choose a <start>. But they do that; Git doesn't.

²Remember, after computing the merge base commit, Git effectively runs:

git diff --find-renames <base> L # see what we did on --ours git diff --find-renames <base> R # see what they did on --theirs 

and then tries to combine these two sets of changes into one big "everyone's changes since the base" change-set, and apply the combined changes to whatever is in the <base> commit. We have just made the claim that <base> and R are the same commit, so there must be no changes at all here. The result of such a merge would match commit L exactly. In fact, though, Git would say "already up to date" and refuse to do anything, for this case.