Given that I have two branches dev and master
I do most of development on dev and then make a merge to master with --no-ff.
Because I used --no-ff, there is a new commit created on master (Let's call this commit A).
Should I fast-forward commit A onto my dev branch before I continue to develop on dev?
Is there any benefit of bringing commit A onto my dev? Would it be an anti-pattern to bring this commit A onto dev branch?
There is neither any real cost, nor any real benefit.
Remember that branch names are largely ephemeral, and in any case certainly evolve over time. If you keep both names around for a long time—the one named master, you'll probably keep—then at some time in the future, you would see this pattern of commits:
(time increasing towards the right)
o--o---------M-----N <-- master
\ / /
o--o--o--o--o <-- dev
for the first case, where you git merge --no-ff dev into master to create merge M at some time T, and then git merge again to create merge N at some later time.
If you allow dev to rejoin master at M, you will instead get:
o--o---------M------N <-- master
\ / \ /
o--o--o o--o <-- dev
Is this better? Is it worse? Will you care?
If you take away the dev name, and instead use feature names, you might see:
o--o---------M------N <-- master
\ / \ /
o--o--o o--o
where the first bubble along the bottom row was temporary name feature/foo and the second bubble was temporary name feature/zorg.
Again, the real question will be: do you care? The only things that are permanent here are the commits themselves. Make the commit messages good—the default merge ... messages are kind of terrible, but at least something like:
merge branch feature/foo
and:
merge branch feature/zorg
offer some clue as to what this was about. Compare with:
merge branch dev
which tells you nothing at all, regardless of which stitch pattern you observe in the commits.