0

I work in a team, and while I try to update the branches I'm working on with the changes my teammates merged into our dev branch by rebasing or merging, sometimes, I have conflicts in various files/lines that are not related to each other. I would like to resolve unrelated conflicts separately so that each resolution has a meaningful commit message rather than one commit for them all. From the searching I did, it seems to me that a merge strategy is an all-or-nothing kind of thing, and if I would like to interactively resolve conflicts, I could use git interactive rebase, however, in various docs I've read, they all say that you must not rebase a public branch as it creates new commits and "rewrites" the history of the branch. I was hoping someone could help me understand how to gradually resolve conflicts rather than resolve them all in doing one commit using some known practice (rather than some workarounds).

  • It's true that rebase "rewrites history". It does so by creating new-and-improved commits (well, we *hope* they are improved), thereby forcing everyone who has, and depends on, the old (and lousy?) commits to do their own rebases as well, so as to move *their* commits atop the new history. **As long as all parties have agreed to do this** there's nothing wrong with rebasing. You just need to get other users of the name that will be used to *find* the commits to agree. – torek Jun 15 '22 at 09:13
  • This doesn't affect the need to resolve merge conflicts all at once. But by rebasing, you can wind up with fewer conflicts per commit, and all the conflicts you need to resolve are those involved in a single, self-related commit. So that's pretty clearly the way to go here. – torek Jun 15 '22 at 09:16

0 Answers0