-1

I have a large number of commits (hundreds) that belong to a specific branch, that was merged to master long time ago (there are new commits after that merge). Any idea on how do I remove those commits from master?. Not one by one with git-revert as suggested. More like a filter-branch command. Thank you

Cezar
  • 1
  • 1
  • You want to take them back like "removing them from the history of the branch as if they didn't happen ever" (rewriting branch history) or you want to "apply commits following the current history of the branch that will take those changes back" (reverting, which doesn't require rewriting)? – eftshift0 Jun 05 '17 at 14:01
  • Possible duplicate of [Git delete pushed commits](https://stackoverflow.com/questions/13577283/git-delete-pushed-commits) – legoscia Jun 05 '17 at 14:12
  • @Edmundo first option: removing them from the history of the master branch as if they didn't happen ever – Cezar Jun 05 '17 at 14:52

1 Answers1

0

Then what you have to do is fairly simple: Identify the revision before the branch you want to remove from history was merged. Check out this revision.... then cherry-pick all revisions following the merge.

Suppose the revision before the merge is revision A, merge revision is B and the branch you are working is called 'someBranch'. Then, you could do this:

git checkout A
git cherry-pick B..someBranch

If you like the results, then you can repoint someBranch to the current revision:

git branch -f someBranch
git checkout someBranch

When you rewrite a branch and other people are working on the "old branch", then there is friction in order to push this new "rewritten" history, so keep that in mind.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • After that merge, there are hundreds of commits. Don't want to cherry pick them one by one. Sorry for not being more specific – Cezar Jun 05 '17 at 15:16
  • If it's a linear flow, B..someBranch will apply _all_ of them, so you won't have to cherry-pick one by one. If it's not a linear flow, then you might consider using rebase instead. Something like: ```git rebase -p --onto A B someBranch``` if I'm not wrong. – eftshift0 Jun 05 '17 at 15:43
  • the rebase would do the trick if there were no conflicts on the 270 child commits (merges) when doing the rebase. I can solve them one by one but it is not what i'm looking for – Cezar Jun 07 '17 at 08:07