Re-merging a rebased branch - how is it usually done?

Question

git

Often an interesting situation began to arise with the git and several developers. Suppose there are master branches and 2 developer branches, devel1 and devel2.
But at the same time, we decided not to take the C10 commit from the first one, so we made a rebased branch without it and, accordingly, with the modified C11'

Then we made a devel2 merge and rebased to the master

However, at this time, the developers in the devel1 branch continue to make new commits:

Over time, we wanted to freeze their new work in master again, and here problems arise:
1. If we did
> git checkout master
> git merge
devel1 still)
2. If we did
> git checkout master
> git cherry-pick C14
It seems to be what we need, but git does not know that we organized the merge in this way, and subsequently, when changing around these places and a new merge, we will get a conflict. Well, in addition, we need to manually select the commits that need to be “added”.
3. If, after creating rebased, do
> git checkout devel1
> git reset --hard rebased
Then the developers will not be able to push due to conflicts, and C10 will be lost (perhaps it will be needed later after editing), which is also bad.
In general, for some reason it seems to me that there should be some mechanism to reverse the commit, so that neither it nor the reversed commit is displayed in the history, but at the same time the git does not try to reapply it, and the merges go smoothly, without having to remember "I don't need to pick this commit yet", and without duplicating commits.
The situation is quite common, I guess I just missed something!

Answer 1

I offer this option. Instead of spawning rebased, you merge devel1 into master with the --no-commit (and --no-ff) option.
This is a workflow simulation with a merge conflict - before finalizing the merge commit, git will give you the opportunity to make arbitrary changes.
Next, you roll back the changes from the C10 commit, and commit.

Answer 2

mejedi, and what will it give? In this case, there will be no code from C10, and when the branch is subsequently merged, it will “resurrect” itself again. But it is necessary just the opposite, so that it is, but by default it does not “resurrect” (and preferably does not hang in the history of this branch). Is there no such mechanism?