1

I've come across a situation that I'm not too sure on how best to recover from. A developer had created a branch from a very old version of "master". After realising, they merged the master branch in to their new branch. After a couple of weeks of work done on this branch, they are trying to merge it back in to master. It's producing thousands of changed files in the diff, showing that hundreds of files have been added or deleted.

Am I write in thinking the best way to recover from this is to make a new branch based off master, and cherry pick their commits (oldest commits first) over to the new branch?

Martin Blore
  • 2,125
  • 4
  • 22
  • 34
  • Yes, I think you should create a new branch and switch to the particular commit by cherry-picking it. – Neha Nov 06 '17 at 18:40
  • why do you want to cherry-pick if you can merge? – OznOg Nov 06 '17 at 18:41
  • There actually about 30ish commits done by 2 people on this bad branch. So if I play their commits on to the new branch, oldest first and in order they committed, that should give me the least pain, right? – Martin Blore Nov 06 '17 at 18:41
  • If you attempt to merge the master over the branch, this is when it shows >500 changes in files being added/removed, when in reality, they haven't changed at all in the time their branch was created 2 weeks ago. – Martin Blore Nov 06 '17 at 18:45
  • A simple `git rebase master` from your current branch would do. See [this answer](https://stackoverflow.com/a/1994491/7598462) and the [rebase documentation](https://git-scm.com/docs/git-rebase) describing very similar examples. – kowsky Nov 07 '17 at 07:18

0 Answers0