You have this history (time flows left to right):
... ...
\ \
----------M--o--R--o <-- develop
/
--1--2--3--F <-- feature
You have created commits 1, 2, 3 on your feature branch and merged it into develop at commit M. Then you discovered that there is a bug and reverted it at commit R (before or after other branches have been merged; it does not matter).
Now you have fixed the problem with commit F and you want to merge the feature again. This brings a lot of trouble (merge conflicts), because F depends on the changes you made on the feature branch, but develop no longer has them (you have reverted them in R).
One way out is that your revert the revert and then merge the updated feature branch:
git checkout develop
git revert R
git merge feature
That should not produce the merge conflicts, but result in this history:
... ...
\ \
----------M--o--R--o--R'--N <-- develop
/ /
--1--2--3--F------------' <-- feature
R' is the reversal of the revert R.
Another method is to make Git think that the earlier merge has never happend using git replace --graft as described in this answer.
Yet another method is to create a completely new feature branch. Assuming 1 is the first commit that was merged in M, it could go like this:
git checkout feature
git rebase --force-rebase 1^
git checkout develop
git merge feature
git rebase --force-rebase 1^ ensures that commits 1, 2, 3, F are copied and creates a new branch that forks off at the same point that the original branch forked off. You get this history:
... ...
\ \
----------M--o--R--o--N <-- develop
/ /
--1--2--3--F / <-- abandoned feature branch
--1'--2'--3'--F'---' <-- feature
Of course, you can choose a new fork point for the feature branch. R would be the natural choice.
