Problem Statement:

I have 2 main branches: master(PROD) & dev(UAT). Whenever my team receives a change request on the application, we create a branch from master do our changes, and before merging the branch into master, we do "git pull origin master", so that our branch code must be in sync with master code.

At starting of February, my colleague merged a branch into master. But here the branch was not created from master. So the master got polluted. I reverted the changes but the revert was not proper. What I did was "git revert -m 2". After the revert commit, there are 3 merge commits on master.

I have the last commit id till where the master branch was not polluted. My main concern is that I want the master to be clean.

Questions:

1. How to get back to the commit which will make the master clean?
2. There are branches which are in sync with polluted master. How to clean the master in such a way that reverted actions of master applies to the branch as well?

Thanks in advance.

PS: I don't have any GUI tools.

CodePudding user response：

If you know the good point where you want it to be (like good123), then the easiest way to come back to the pristine state locally is:

git checkout master
git reset --hard good123

This will make your local master as if nothing has happened after good123.

If you want the server (origin/master) to be in the same state, then you'd need to "force push". This is dangerous, as it will overwrite the remote state, and force your peers to handle the situation. Make sure you have a backup first.

git push -f origin

Any other person in the team would need to make a new branch for their work (e.g. mytask2) and re-sync with this updated master. The best way depends on how much work did they do on top of the "polluted" state. In the simplest case where they've had just a single commit mytaskcommit123 before "contamination" is to do a "cherry pick":

git fetch origin
git checkout master
git reset --hard origin/master
git checkout -b mytask2
git cherry-pick mytaskcommit123

Note that in git there's no single master. Each developer has 2 copies of master:

• local PC: master
• remote server: origin/master

So each developer would need to update both. In the script above "fetch" updates the remote one, and "reset" updates the local one.

For more complex cases git rebase -i or git reset --mixed can be helpful.

Depending on how much work is it, consider keeping the polluted history the way it is, and just reverting the broken commit.

CodePudding user response：

What I did was "git revert -m 2". After the revert commit, there are 3 merge commits on master.

First of all, git revert does not remove any commits. That is the whole point of git revert. So if your complaint is that the merge commits are still there, that is normal and you should not be complaining about it.

On the other hand, it looks like you gave the wrong command. The way to revert a merge commit so that the incoming branch has no effect on the mainline branch is to say

git revert -m 1 <SHA>

In other words, you said -m 2 when you should have said -m 1.

You have two choices at this point.

• One possibility is to revert the bad revert, and then do a good revert.

• The other possibility is just to reset --hard back to the state of things before the bad merge(s) — but that is frowned upon if this is shared material, as it can make everyone else's life very difficult.