0

Basically, whatever modifications I do in a single file, when I get to push to master, conflicts happens on those specific places. So imagine I only modify 3 comments in a file, then I would get conflict in those 3 specific lines.

What I do is create a feature branch from develop, modify a file, merge back to develop. From develop, I create a release branch, and that branch then gets merged to master, something like this:

D-----------∞
 \ /  \
  F    R--->M

When I merge R--->M (release->master), I get conflicts. After solving it, if I do same flow again, I will get conflict again on whatever I changed.

I can even replicate it in my local, it happens everytime. Am I missing something?

mike
  • 1,233
  • 1
  • 15
  • 36
bwk4u
  • 25
  • 7
  • Since you can reproduce it locally, can you provide a [minimal, reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of what you are doing? – Malice Jun 19 '20 at 11:33
  • If you merge, resolve conflicts, then change that file **only on one of the branches** and merge again, and you get new conflicts, then you have something funky going on. Could it be line endings that you have configured incorrectly? – Lasse V. Karlsen Jun 19 '20 at 11:46
  • @Malice I don't think that's possible since I'm branching of a private repo which already has history, I don't see a way to "re-create" it. – bwk4u Jun 19 '20 at 12:34
  • I’m betting that you are using the word “merge” incorrectly. This sort of error is the sort of thing I would expect with e.g. GitHub’s horrible squash-and-merge feature. Use true merges with merge commits. – matt Jun 19 '20 at 12:35
  • @LasseV.Karlsen That's exactly what happens when I push to Github. If I test it locally, first time I get conflicts, but if I modify develop again and try to merge into master, didn't get conflicts. So this behavior is only happening when actually pushing this changes to remote, not **fully** reproducible in local. – bwk4u Jun 19 '20 at 12:54
  • @matt We use Azure DevOps and we have branch policies, so we can't directly commit to develop or master, we create PR's which take care of the merge (and yes, merges there are squash as default, but that's they way we have it in **all** of our repos and none of the other repo has this problem). – bwk4u Jun 19 '20 at 13:12
  • Ok but the "none of the other repo" is sort of an implementation detail. The point is that a squash is not a merge, so it is misleading to describe it as one. (Not your fault, really; git is the source of this mistaken terminology.) You might want to step back and rewrite the question to describe the reality more accurately; that will make it easier to help. – matt Jun 19 '20 at 13:15

0 Answers0