In our organization we git rebase our branches. We rebase onto master periodically to keep things up-to-date, and git push --force-with-lease, then let any other devs know.
Developer A was working with Developer B on a branch. Developer B rebased onto master and force-pushed the branch.
Developer A made a mistake and continued working, and when he tried to push, it looks like he got a conflict and merged the rebased branch into his local, then pushed.
No one noticed, and he did it again a few days later.
So now the git history contains the same commits two or three times, and is a disaster to rebase onto master.
Is there a way to solve this?
Would it be best to make a new branch off master and cherry-pick the non-duplicate commits? Does it matter which commit gets cherry-picked, in the case of duplicates?
Would it be best to make a new branch off master and cherry-pick the non-duplicate commits?
"Best" is always tricky, but this is a good approach.
Does it matter which commit gets cherry-picked, in the case of duplicates?
If they are truly duplicates, no. But if they do something slightly different—if one was a duplicate from a rebase or cherry-pick that had a merge conflict, for instance, and was resolved manually—they might be "mostly the same, but slightly different", and then it would matter.
The nice thing about building an all-new branch is that you can verify, at the end, that it does whatever it was supposed to do, and that the difference between its final commit, and the final commit of the current one, is only whatever you expect to be different. Meanwhile the original series of commits is easily available.