Best practice for modifying an already-merged git topic branch

Question

We use the following git workflow at my company when coding up a new story:

1. Create a topic branch off of master (production/stable)
2. Create as many commits as desired to implement feature.
3. do a git merge --squash of that topic branch onto the qa branch.
4. QA people review.
5. If good, the code is merged into the ua branch. If the User Acceptance team blesses it, it gets merged to master and ultimately deployed.
6. If it fails review, the developer needs to fix. Essentially restarting the process at step 2.

Note: It can be up to two weeks from the point code is merged to qa branch and the time qa rejects/accepts it.

If there are no issues, then the code eventually makes it into master. However, I'm seeking best practices for when QA finds an issue and you have to fix it. What I'd like is to end up with a qa branch looking as "pristine" as possible.

As I see it, here are the options:

1. Revert the original squashed commit in qa branch, rebase topic branch off of qa, fix your code in the topic branch, merge it into qa again. Problem: leaves icky revert commit around.
2. Delete existing topic branch, recreate it from qa branch, create a simple commit to fix problem, merge back into qa. Problem: spreads code changes for feature across commits distinct in time and place.
3. Do away with squashed merges to qa, rebase individual commits from qa to existing topic branch, fix with another commit, merge into qa. Problem: multiple commits make it difficult to track changes as they move to ua branch and then to master.

Question: Is there a best practice for moving multiple commits for a single feature through multiple long-lived branches (master -> topic -> qa -> ua -> master) when merged code may need to be fixed?

Answer 1

From experience, the idea to keep one branch to fix what is found in qa or ua or master doesn't go very well, as it artificially links together (within a same branch) what ends up being different development efforts altogether.
The bug you are fixing after 'qa' are generally more straightforward (because found sooner in the development life-cycle) than the ones found in 'ua' or in 'master'.

So I would go with 2., but without the 'delete topic branch' part, only with 'create new topic branches' for the specific fixes/evolutions you need to do along the development cycle.