I want to reset master to a previous commit, but I also want a PR for my team to approve.

So far I did this:

1. create a local branch from master
2. git reset --hard d94kjf8
3. push to remote

Now when I go in github to create a PR, it says "master is up to date with all commits from mybranch" so there is no difference to make the PR from.

What should I do differently, in order to reset master, while using our review process?

CodePudding user response：

You can't.

It's not possible to perform a git reset by using a merge or PR. Instead, you have two options:

1. Do the reset of master locally somewhere, and then force push out to the remote. (You may need special permissions, even if just temporary, to force push master.) This is generally frowned upon, which is why it's oftentimes restricted.
2. You can instead use the revert command for each commit (or merge commit) that you wish to "undo". Reverts create new commits which are the opposite of the commits getting reverted. Then you can PR those new commits into master.

CodePudding user response：

It's crucial to understanding git to know that branches are not a sequence of patches or instructions, they are a pointer to a single commit. From that one pointer, the rest of the history is accessible backwards in time by following "parent" pointers.

The command git reset --hard d94kjf8 moves the pointer of your current branch to commit d94kjf8. This isn't an action that can be recorded in history, reviewed, or merged - it is just a direct instruction to git to change a file which records "branch X currently points to commit Y".

To move the pointer of a branch on a remote server, you can use a "forced push", which tells the remote server "forget what your pointer points at, point at this instead". Again, there is no review process here: you issue the command, the server obeys (or refuses to based on restrictions configured on the server), and it is done.

Moving the branch pointer of a shared branch has consequences for everyone who has built their work on top of that branch. Sometimes, it is absolutely the right thing to do, but you and your colleagues need to understand what you're doing, and what else will need fixing afterwards.

Specifically, any branch created from master before you make the change will have as part of its history the commits you want to "skip over". Each of those branches will need to be "rebased", creating a new history as though master had been at commit d94kjf8 when they were created.