0

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?

Offlein
  • 665
  • 6
  • 22
  • Maybe `git rebase -i` could help? Also having 2 developers working on the same branch AND both rebasing it at the same time sounds like asking for trouble. Rebasing is really something I feel should be done when you're working alone on a branch nobody else is using. – Omer Tuchfeld Jul 27 '20 at 14:23

1 Answers1

1

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.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Thanks for the tips! An aside -- a commenter on the question said that rebasing should not be done in multi-developer teams, but my understanding is that this is still relatively common practice. Do you have an opinion? – Offlein Jul 28 '20 at 15:35
  • 2
    Whether (and when) to rebase is really a matter of *agreement* between all the individuals who might be expecting the branch name to behave in some particular fashion. If everyone agrees that branch X gets rebased, and understands how (and when) to handle it, that's fine. Your problem stemmed from two people not agreeing or misunderstanding. The blanket rule "never rebase shared name" is just a way of ensuring that the only person you have to agree with is yourself. :-) – torek Jul 28 '20 at 19:39
  • Indeed, thank you. My engineer in question is aware of this (and presumably knows how to do this) but something has gone awry. Thanks! – Offlein Jul 29 '20 at 21:24