git merge manipulates the history

Question

In our team, the regular procedure is that when we have a significant feature we work on a feature branch.
Every now and then - we merge from master to out feature branch and when we're ready - we merge back to master (usually through a pull request).

The problem is that as after the merge the commits history are mixed - we don't have a simple way to role back the branch-merging operation, to exclude the branch in case we find it problematic.

We were considering a few alternatives:

1. instead of merging master to the feature branch - rebase the branch on top of master, so that the feature commits appear last in the log.
   This would ease it removal but we're still in the same problem if someone didn't follow this rule)

2. Instead of merging the branch back to master - rebase the feature branch on top of it. this will probably mean we can no longer use pull requests.

3. Have a script tag master daily.
   As the occasions we need to exclude an already merged branch are very rare - we can probably examine and consider the commits since yesterday one by one. this sounds very hacky but it doesn't stand in the way we currently do things in here

What is the best practice here?

Answer 1

instead of merging the branch back to master - rebase the feature branch on top of it. this will pr?bably mean we can no longer use pull requests.

Yes, you will be able to use the PR, after force pushing your rebased branch to your fork.
A pull-request is able to follow multiple rewrite of a branch history.

Note that 1 is strangely similar to 2 here: "rebase the branch on top of master" vs. "rebase the feature branch on top of it (master)".

But in any case, rebasing feature on top of master is the prefered workflow before a PR.