Yes, ff-only will fail. If C,D are independent and simple, I would go ahead and rebase, otherwise do a proper merge.
Remember you can play a lot with git; if you are not sure how it will turn out, checkout a commit (e.g. git checkout origin/master), create a new throwaway branch (git checkout -b tmp), then you can do rebases, cherry-picks, merges etc., then do "git log tmp" or "git log -p tmp" to see how does the branch look. If you are unhappy, you can always throw it out (git branch -D tmp), it won't affect anything else.
I generally avoid the situation when a branch and origin diverges. The flow I have in my work is: If I need to make a small change (few lines), I pull, do changes, commit and push directly to master; if there are any intervening independent changes, pull --rebase. For anything larger, I create a new branch, and commit there. Once it is ready, I give it to a teammate for code review and do automated build, if everything is OK he merges it to master. Other people generally don't push to my branch, and there is no A-B-C vs A-B-D situation.
If several people work together on the same branch, we coordinate actions face-to-face or via team chat, to avoid conflicts. We pull/push many times a day and the changes are small enough so there are no problems with rebasing in a topic branch. If two people make big conflicting changes to the same branch, it means trouble and we merge or even discard some changes.
Remember you can play a lot with git; if you are not sure how it will turn out, checkout a commit (e.g. git checkout origin/master), create a new throwaway branch (git checkout -b tmp), then you can do rebases, cherry-picks, merges etc., then do "git log tmp" or "git log -p tmp" to see how does the branch look. If you are unhappy, you can always throw it out (git branch -D tmp), it won't affect anything else.
I generally avoid the situation when a branch and origin diverges. The flow I have in my work is: If I need to make a small change (few lines), I pull, do changes, commit and push directly to master; if there are any intervening independent changes, pull --rebase. For anything larger, I create a new branch, and commit there. Once it is ready, I give it to a teammate for code review and do automated build, if everything is OK he merges it to master. Other people generally don't push to my branch, and there is no A-B-C vs A-B-D situation.
If several people work together on the same branch, we coordinate actions face-to-face or via team chat, to avoid conflicts. We pull/push many times a day and the changes are small enough so there are no problems with rebasing in a topic branch. If two people make big conflicting changes to the same branch, it means trouble and we merge or even discard some changes.