-1

I had a feature branch and a PR on github. This branch had many commits. I eventually merged the PR into master (did not squash all my commits into 1, so theres still ~50 commits that got put into master's history).

I'd like to undo that merge completely (along with all the commits that came from my feature branch along with the merge). I know I can do git reset --hard <sha before merge> but would that also remove all the commits that came into master from my feature branch as a result of the PR merge?

Abdul Ahmad
  • 9,673
  • 16
  • 64
  • 127
  • You can `git rebase -i ` and drop the commits you don't want. – Sergio Tulentsev Feb 01 '23 at 17:09
  • And going forward, I would advise to squash the branches you're merging. – Sergio Tulentsev Feb 01 '23 at 17:11
  • yep... lesson learned. – Abdul Ahmad Feb 01 '23 at 17:12
  • 2
    I would advice against squashing down everything to one commit when merging. It looses valuable history, **especially for future use when you are trying to debug some problem with [git bisect](https://git-scm.com/docs/git-bisect)**. If you are concerned with perhaps having previously added some debug code earlier that later is removed but you do not want to have added permanently to the history *that is good thinking*, but the remedy is to ensure proper version hygiene by using [temporary commits](https://stackoverflow.com/a/75010635/23118), not to flatten everything into one commit. – hlovdal Feb 01 '23 at 18:08
  • Some tools have a button in the UI to assist with reverting a merge. But behind the scenes they are all simply helping you do this: Does this answer your question? [How do I revert a merge commit that has already been pushed to remote?](https://stackoverflow.com/questions/7099833/how-do-i-revert-a-merge-commit-that-has-already-been-pushed-to-remote) – TTT Feb 01 '23 at 23:48
  • @TTT yea it does. i'll accept that as the answer – Abdul Ahmad Feb 02 '23 at 17:15
  • @AbdulAhmad I'm not comfortable writing that up as an answer since it implies this question should be closed as a duplicate of that one. Even if you modified your question to ask how to do it in GitHub, then it would be a dup of [this question](https://stackoverflow.com/q/6481575/184546). IMHO this question should probably be closed as a dup referencing one of those. – TTT Feb 02 '23 at 18:01
  • 1
    @TTT yea that makes sense, I can close it and reference the other answer – Abdul Ahmad Feb 02 '23 at 18:47

2 Answers2

0

looks like github has a 'revert' button on the merged PR - it will create a new PR to undo all the changes. I will go with that option. thanks all

Abdul Ahmad
  • 9,673
  • 16
  • 64
  • 127
-3

You can use git rebase -i HEAD~<number of commits> then squash all the commits into one. But the catch here, you have to force push the master branch.

It's always the best practice to squash all commits and rebasing with latest master of the branch you are merging before merging that into master. Cheers!

mehmoodahmadq
  • 111
  • 9
  • but i merged into master, which also has other commits. with this approach i'd have to manually go through each commit (mine and not mine) and decide to keep/remove it? – Abdul Ahmad Feb 01 '23 at 17:21
  • Do you have that feature branch? – mehmoodahmadq Feb 01 '23 at 17:23
  • yea i have the feature branch – Abdul Ahmad Feb 01 '23 at 17:25
  • 3
    No, that isn't "always the best practice". It's purely a matter of convention and opinion. I happen to think it's a very silly thing to do actually. History is good. – matt Feb 01 '23 at 17:25
  • Okay great, according to my experience it's best that you drop all the commits (remove one by one) from master. Then rebase your feature branch with master and then merge it with or without squashing. – mehmoodahmadq Feb 01 '23 at 17:26
  • Yes @matt. The thing is if many devs are working in a team and you can keep one commit per branch. That is good then. But agree with you too, that totally depends on the development process you are following. So, perspective, you know. – mehmoodahmadq Feb 01 '23 at 17:28
  • 1
    And my perspective is that you shouldn't tell a beginner that squashing away history is "best practice". It isn't. – matt Feb 01 '23 at 20:18