The problem you're going to have is that—and bear with me, here—commits aren't "on" branches. To see this, consider the graph you drew. It's ambiguous. Unavoidably so. You drew
A---C---D---E master
\
B---F---G---H feature
\
J---k---L another
and there is simply no way to determine whether B
was made "on" feature
or another
(or, for that matter, which of the three A
was made "on").
A---C---D---E master
\
B---J---K---L another
\
F---G---H feature
shows exactly the same history. It's all in how you choose to interpret it.
If you want to tie a commit to some external administrative record, put a marker in the commit message, that'll do it, but in Git itself (and to the actual work) it's the history structure that matters, not how bits of it are referred to in this repo or that.
If it comes time to publish feature
or another
, you're going to need to push commit B
either way, unless it's already been pushed as part of some other work. Ancestry matters. Branch names don't.