I was working simultaneously on a Feature branch and Master branch.
Few days ago I merged my Feature into Master. A few commits have been made on top of that too.
But later I realised that the feature is no more desired. So I need to remove the commits which have been incorporated due to the Feature branch.
On checking, I realised that I have 3 options Rebase, Revert and Cherry-pick.
I might need the commits of the Feature branch in future. Therefore, it's commits need to be visible in commit history/ git log etc, if I need them in the future. Hence, I am confused which option of the above three to pick.
Note: All the commits are pushed to master. So would that have any implications on the option I pick?
Because your branch is already published, you probably want to avoid using an interactive rebase as a solution. The interactive rebase would allow you to literally excise the Feature commits from Master which you don't want. But this would happen at the cost of rewriting the history of Master, which can have negative implications.
I think the best option for you would be to git revert the Feature commits which you do not want.
Use:
git revert <SHA-1>
where <SHA-1> is a commit you want to revert. If you have a series of commits in order, then you can use:
git revert --no-edit <SHA-1>..<SHA-1>
using a range of two commits.
There is no way to have the commits in your history for later use. Either the commits are there, or they are not.
If you want to bring back the commits later, you can either merge or cherry-pick them in, or you could also revert the revert commits (@1615903).