Post History

> I think a branch is a set of commits and a commit is a set of deltas, so my concern is that merging feature-B to master would reflect only the work that is unique to feature-B

Not quite: a branch is a pointer to the *state* of a repository at a particular point in time (as represented by the commit that created that state).

Merging branch X onto a branch Y proceeds by 

- finding the common ancestor in the histories of X and Y
- create a merge commit pointing to the last commits in both branches (or reuse the last commit from X if there has been no other commit in Y, and [fast forward](https://stackoverflow.com/questions/9069061/what-is-the-difference-between-git-merge-and-git-merge-no-ff) is enabled)
- update Y to point to this commit

That is, merging a branch will merge the entire history of that branch (that the target branch doesn't have yet) regardless of which branch the changes were originally committed to.

In your case, this means that merging B will also merge all changes done in A, because they are part of the history of B, and not on master yet. If you were to later merge A, git would realize that all commits are already on master, and merge nothing.

This can be a blessing or a curse. A blessing, because it ensures that prior work is automatically merged; a curse, because that work may not be ready for release yet. 

> feature-A and feature-B are both on master and arrive in that order (or together)

To achieve this, you can merge A and then merge B, or just merge B. Either way, git will apply the commits of both branches in the proper order. 

The only difference is the commit message of the merge commit (if one is created), which mentions the name of the branch being merged. If it is important to note for posterity which work was done in branch A, it may be preferable to merge A before merging B (without fast forward), so separate merge commits are created, with the merge commit for A separating the commits done A from those done in B even if the branches themselves should later be deleted.

> it remains possible to backport feature-A without bringing along feature-B in the future 

Don't merge B onto A, then (even if you did, you could still backport by resetting the A branch to the commit before the merge, but its easier to not merge B into A to begin with).