Search code examples
gitxamarin.formsatlassian-sourcetreevisual-studio-mac

Mac SourceTree merge seems to break branch

Working in Visual Studio Mac on a Xamarin.forms project.

So:

  • I had a bug with something called DeviceTokens in my "development" branch
  • I went back and found a commit that didn't have the bug
  • I made a branch from it called "doesNotHaveDeviceTokenBug"
  • I fixed the bug & the project runs just fine... from that branch

So now I want to merge the fixes back into my other branch, right?

So I switch back to "development" and I do this:

enter image description here

..and then this:

enter image description here

...and I get a warning about conflicts:

enter image description here

...and I resolve them all using "theirs", because that's what I want, right?

enter image description here

...and then here's the thing...

...now my project won't run.

If I switch back to the "doesNotHaveDeviceTokenBug" branch, the project still works great.

But when I'm in"development", I get a ton of errors.

...I don't get it. I fixed a bug, and now I want to merge that fix back into its original branch--isn't that the whole point of this thing??

What am I doing wrong?

Solution

  • I use SourceTree on Mac a lot, and I'm very fond of it, but I would never in a million years merge "blind" like that. When you merge doesNotHave... into development and you get a merge conflict, stop and look at the file(s) that are conflicted and resolve the conflict(s) yourself directly in those files. Your last screen shot shows the conflicted files with their conflict markers; you just edit those directly with your favorite text editor, and when you're all done, you mark them resolved and let the merge continue.

    So I would suggest doing a hard reset of development back to c2c8c50c and doing the merge again, and this time, look at what's happening during the conflict and make sure it all makes sense to you as you resolve it.

    Also, you seem to think that a merge with a conflict resolved by the theirs strategy is going to be identical to theirs. In other words, you are saying: hey, this tested out fine on doesNotHave... before the merge, so it should test out fine on development after the merge.

    But there is a lot more to a merge than that. Both sides of the merge can make contributions. So no matter how you resolve the conflicts within particular files, you may still be combining your contributions on doesNotHave... with contributions from develop that don't play well together.