Each Git is its own independent entity, and can make up its own rules (or have them made up for it by some Git administrator anyway).
It seems that the Git at the machine / URL that you are calling gitlab has easy rules that permit commits with bogus or missing committer name and/or email addresses, and your own Git on your machine is equally permissive. The Git over on the URL that you are calling bitbucket, though, is stricter.
Those commits in master were made by someone else, but the merge into branchA was made by me.
Is it possible to solve this problem?
Not at your end, no. You can sidestep it, at some cost, but you cannot solve it.
Fundamentally, the issue is that the commit objects you obtained from the Git at gitlab and have stored into your own Git repository don't meet the requirements imposed by the Git at bitbucket. Moreover, every Git object is read-only: once made, it can never be changed. The only way those existing Git objects would pass the requirements imposed by the Git at bitbucket is if those requirements are loosened.
That might be possible, but is not something you can do at your end. You can do it at the Bitbucket end of the connection if you have enough administrator privileges there and/or they (the Bitbucket folks) have provided appropriate knobs to set to control its strictness.
Alternatively, you can, while leaving these commit objects alone, make new and improved commit objects that are very much like the originals, but have corrected whatever it is that the Git at bitbucket is objecting to. You can then merge your work with these new-and-improved commits, and push the result to the Git at bitbucket, who will presumably now be happy with them. That's what I call "sidestepping" above. You haven't actually fixed anything: the broken (in the eyes of the Git at bitbucket anyway) commits are still broken. You're just no longer using them, at least in terms of sending stuff to the Git at bitbucket.
To copy commits one-at-a-time, you can use git cherry-pick. The resulting commits will have the original author as author, and you as committer, by default. To copy commits en-masse, you can use git rebase (which is a little bit tricky in various ways) or git filter-branch (which gives you enormous control over the copying process, but is a lot tricky in several ways because along with all that control, you must actually know what all the controls do).
In any case, your new copies will not be the same as the originals—that's necessarily the case, since the originals cannot be changed—and will create headaches for everyone who needs to use both the originals and the new copies (this probably includes yourself). So it may not be the way to go, unless you can somehow convince everyone to switch over to the new "corrected" commits.
