One mistake that I saw several times is cherry picking or merging another branch into the current one, then realizing later that you didn't need those changes yet, and you revert the merge commit. Later, if you actually want to merge the other branch into the current one you will get in trouble as it's already "up to date", as the current branch is ahead. Even worse, if you instead merge the current branch into the other one, all your changes done in the other branch will be reverted. The takeaway: don't revert something if you don't actually want to revert that code. I am pretty bad with git, by I assume the correct way to reverse the initial merging would be to remove that merge commit entirely, using git reset.
I think both answers are correct, and the best thing is to understand where each approach will bite you.
I prefer to remove the commit because I am proponent of rebasing over merging. Though the issue is that removing merged can be tricky, because you have the merge commit as well as all the commits associated with the merge. It’s easier for me to manage by avoiding merges entirely, and just restructuring git history via rebases often.
Biggest issue is the first part, when it's "already up to date", so then when you merge the feature into the current branch and think it's merged, it will actually be missing, so you might forget to revert the revert, or not work anymore because of new commits/conflicts.
I honestly can't say I have ever had this problem. I also don't understand how you could forget to revert the revert? And why would new commits matter? Sure you may have conflicts, but you would have had them anyway if you hadn't reverted.
We've had to revert commits on our master branch after several commits have been added on top before, and we've never had an issue just checking out a branch off master and reverting the revert commit.
I feel like there are workflow things you could be doing to avoid whatever problems you're encountering possibly?
You can easily forget if someone else (not yourself) did this (they merge the branch and reverted it), later when you try to merge the branch it could be successful, without any merge conflicts, but still won't lead to the expected changes.
OK I suppose that is more likely, but I still think this is easily-avoidable through process. If you're closely-enough involved with a ticket that you were going to be the one merging it, I think it's reasonable to expect that you have an idea of things that have happened in the story.
