Git Rebase repeats conflicts from last Rebase

Question

Are there any common git usage mistakes or in general any reasons at all why a rebase would repeat the conflicts from the previous rebase if those conflicts had all been resolved in the previous rebase?
Furthermore, does rebase have a preference over how the conflict was resolved? e.g. does rebase want a strict choice between the two possible code snippets in the usual git conflict brackets within the code or is it just as fare to it to remove everything between the >>>,<<<? I'm curious if removing both code choices to resolve the conflict will affect rebase's ability to resolve later conflicts properly.

Further elaboration: I have a master branch and a dev branch. The dev branch I've been working on the side for some time so the number of differing commits has grown quite large, in the 100s (I know...should dev into master more often). dev branch itself has had several smaller feature branches cut from it and then merged back in, only ever having been cut, rebased, merged with dev branch and never master branch (that I can remember). I rebased dev branch onto master branch 1 week ago. I have since made a few more changes on dev branch and would like to rebase on master once again so I can prepare for a merge. There has been a very small change to master branch in that 1 week window as well but the code files don't overlap. However, when rebasing dev onto master I'm seeing the same set of conflicts being raised by git when I attempt the current rebase as compared to when I rebased one week ago.

Thanks!

Answer 1

In general, it's normal - if you rebase like this rather than merging (eg. master into dev), then replaying the same patches will likely generate the same conflicts.

You can use git rerere to remember your resolutions if this is a common problem in your workflow.