Let's say,

1. We made commit #100 to master.
2. We want to make commit #101 in a branch go to master
3. However, since there is potentially some issue with commit #100, so we want to go to commit #99 and then cherry-pick #101 and make a PR
4. But we found the PR (Pull Request) does not contain the "reverse" of commit #100.

How can it be made to happen?

The exact steps we did:

git checkout 3f6231        # the commit ID for commit #99
git checkout -b some_new_branch
git cherry-pick 523c62     # the commit ID for commit #101
git push --set-upstream origin some_new_branch

and created a PR. So now, we expect in the PR to have the changes of commit #101, but reversed the commit #100 (because we didn't cherry-pick it). However, we saw the PR only contain the changes for commit #101, without the reverse of #100. If we merge it into master, then as expected, we still see the commit #100 changes. How do we omit commit #100? (or in real life it could be a series of them, such as #100a, #100b, #100c, and we'd like to skip them all and go to #101 directly).

CodePudding user response：

If the branch is protected, you need to revert it and create a PR just for that

git checkout -b correcting master
git revert HEAD # revert last revision
git push origin @ # push the branch to origin

Create one MR and merge.

What you wanted to see, see revision 100 fly away from master from your work in some_new_branch, does not work because revision 100 is already part of master and merging won't remove what revision 100 did (that would actually break what merging is about). You might either revert (like I do here) or you might take the branch back (which is technically possible in git but it's not the simplest/cleanest approach to take with shared branches, which is the reason it's not allowed to do in protected branches in gh):

git push -f origin 3f6231:master

If the branch is protected, that will probably fail. I am writing this just for documentation's sake. This is rewriting history for the branch and it has consequences that are outside of the scope of the question.

Another approach would be making your branch the new master.... but, again, that rewrites history

git push -f origin some_new_branch:master
# also make it like that locally
git branch -f master some_new_branch

Another way would be to revert 100 on top of (the original) 101 on the feature branch. That could work fine.

CodePudding user response：

we need to remove commit #100? What if we need to look at what we did at commit #100 later on

Since the commit to remove is already on master, it is not recommended to remove it from the history in the way that you have described. Please use git revert to undo commit #100 by making another commit that reverses the changes.

git revert <sha>

the "reverse" of commit #100

This will truly give you the reverse of #100, rather than the nonexistence of it.

After reverting, #100 and the commit that reverts #100, maybe #102, will still be in the history, so you can look at them anytime.

Reset, restore and revert

Maybe you even want the reverting commit to be #101 / immediately after #100 in the history, and you want the current #101 to be #102 / after the reverting commit.

git revert HEAD~
git rebase -i master
# Reorder the commits

CodePudding user response：

You don't say if this is a public repo, or the size or the team using it or what. You can locally force a chain on master and push that up, something like:

git checkout 3f6231 # the commit you said you wanted
git checkout -B master
git push -f

you would probably need to disable any branch protection while you did it. It might be a good idea to ensure a branch "master_copy", or some such, was added just in case you mess up. If you are a small team and the repo is private, then this technique can work - you would need to tell other team members to ensure their master was up to date, something like:

git checkout origin/master
git branch -D master
git checkout master

run locally. If this is a public repo, it has lots of users and/or things have moved on (people have commits added to the old master) then forget it - the latter unless perhaps you are willing to manually cherry-pick.

You don't really say why you don't want commit 100. If it is a mistake or injects bugs etc then, as said elsewhere, it is best to use git revert. If it contains something it should not (big file/password/file you don't have rights to etc) then something like BFG is perhaps more advisable.