How can I resolve Github Desktop/Unity Merge Conflicts

Unity Engine
1

I’m still learning Unity and how to use GitHub and have been googling for hours but haven’t yet found a solution that I can understand.

I downloaded GitHub Desktop so that I could keep my (main) Unity game file and then work on a game (Feature) in another branch. After hours of work I just got the new feature to work perfectly in my Unity file today.

Through the GitHub Desktop app I:
Committed my changes in (Feature) branch
Pushed Origin
Clicked Create Pull Request in the GitHub Desktop

Github on Google Chrome (https://github.com/) opened but I can’t merge the (Feature) branch to my (main) document because it says there is Merge Conflicts.

This branch has conflicts that must be resolved
Use the web editor or the to resolve conflicts.
Conflicting files
Assets/Scenes/SampleScene.unity
Logs/ApiUpdaterCheck.txt
Logs/AssetImportWorker0-prev.log
Logs/AssetImportWorker1-prev.log
Logs/AssetImportWorker2-prev.log
Logs/AssetImportWorker3-prev.log

I understand people have had problems with merging when more than one person works on a file but I am a solo developer so I am the only one working on it.

Any advice/help you could offer about how I can merge my (Feature) branch and (Main) together would be super appreciated. I don’t want to lose all of the hours of work I just spent making my game feature finally work.

Thank you!

7643914--952636--merge.JPG
7643914--952636--merge.JPG1140×483 41.3 KB

2

If you have made modification to the main branch and to the feature branch, it is exactly as if 2 different people made those modifications, so even if you’re a solo dev you’ll end up with some merging to do.
If you wish to avoid merging, you have to modify only one branch at a time (in which case creating a branch isn’t really useful and you can work in the main branch all the time).

As for your immediate problem, I’ll start by not versioning useless folders.
Only put those folders in the repo:

  • Assets
  • Packages
  • ProjectSettings
    That’s all, do not put the .csproj or .sln files in the GIT repo.
    Here you can find a recent discussion about that topic:
    which folders should I add to git

It means that your conflict is now only about ‘SampleScene.unity’.
A ‘.unity’ file is a scene, it can be either a binary file or a text file depending on how you configured your project.
If it is in text format, it is ‘a bit’ easier to merge, but to be honest it isn’t really any easier.
The thing is, even a minor modification in a scene may completely re-order its content, messing totally with most diff-softwares.
To do a scene merge, there’s no real solution.
When 2 people modified the same scene and want to merge, I’d say that the best way is to use the version with the heaviest modification, and to re-do the other modification.
I know no tools to merge a scene.

When your merge will be resolved and you have no locally modified files, you should ensure that you save the assets in text format.
In the ‘Editor’ options, look for ‘Asset serialization mode’ and set it to ‘Force text’ (should already be as it’s the default setting):

If you had to change the setting, check that everything is working fine in your project, and if it is fine (there’s no reason it wouldn’t be, don’t worry, the check is just because I’m a bit paranoid…) then you can commit (do not make any other modification to the project for this commit).

Using text format will only marginally help you with scene files (or large prefabs), but it will be of great help for other types of files and small prefabs.

2 Likes
3

Thank you so much for the advice and help Gladyon.

It sounds like I won’t be able to make good use of the Branch feature in GitHub since I want to avoid any possibility of Merge Conflicts in future but atleast I can just use my (Main) file and make commits through GitHub desktop as a good way to save my files.

I looked at the links you provided and found my Repository settings on Github Desktop but it looks like the .csproj and .sln files are already in the .gitignore file? Is that right? I attached a .png file of what it looks like.

I’ll make a mental note to only create [Assets, Packages, ProjectSettings] for my next project too. I assume that was a setting at the beginning but I have just forgotten because this is my first GitHub repo.

Okay, so the result is that I can’t merge the scenes. I’ll have to try and copy the work that I did over. I’ll do some google research on that. It seems that I could either export my (Feature) as a package and re-open it in my (Main) file or create Prefabs of my GameObjects etc. I’ll try both and see how I go :slight_smile:

7644052--952651--gitignore.png

4

Yes, your .gitignore file already ignore the .sln and .csproj files, which is good.
I’m not sure there was a correct default configuration for Unity, but as I use GIT directly without using GitHub I may be wrong on that.

You can use the Branch feature, but you’ll have to be extremely careful.
For source code it will work perfectly fine, for small prefabs it should work well enough.
Large prefabs and scene will cause lot of problems.
If you cut a scene in 4 large prefabs, then you can work on one part of the scene (say prefab 1 for example) on a branch, and on another part (prefab 2 for example) in another branch.
If you need to fix a bug or add a feature which will only require modifying code then it’s easy to do it in a branch.
You can modify one scene in a branch, and another scene in another branch without any problem.

As you see, it is possible, you just need to be careful not to modify the same scene on several branches.

But the real question you should ask yourself is, why do you need branching?
Maybe there’s no real reason or maybe you can achieve the same result without branching.

Branching is good when you work in parallel on large features (at least 10 days of work), when you’re alone you rarely do that.

It can also be a good idea to experiment something which has great chances of breaking lot of things, but you can go back return to a previous state without using a branch.

It is also commonly used to fix bugs, one branch per bug, so that you can easily identify ‘patches’, but that’s mostly done on very large projects with dozens of devs, and I’m pretty sure that those ‘patches’ can also be done if you fix the bug in one commit.

The main reason for branches is to when you have to manage several versions of your software.
Unity for example, they are currently maintaining several versions in parallel, they absolutely need to use different branches.
There, I do not see any other way than to use branching. But having to maintain several versions of a software usually means that you have a whole team, most probably several teams, which means that you already have ‘rules’ to avoid that 2 people modify the same scene at the same time (the most common is to ‘lock’ the files, so that only one person can work on it at a given time, and before working on it one must update the file first, that way there’s no merge on that file).

5

Thank you so much for the extra reply and help!
I’m feeling a lot better now that I understand more about how it works. Its good to know that I could still use Branches as long as I created different Scenes. I’ll test that out with a sandbox unity file.

Yeah you are right! As long as I am just doing commits on the (Main) file then I can always revert back changes if I break something :slight_smile: Phew then I won’t have to worry about merge issues.

Oh thats so interesting to know. I’m really glad you replied to my post! Thank you again!!

6

Great explanation. It looks like you have encountered your share of merge conflicts. From your experience, what’s the biggest pain with merge conflict? Is it precisely the merging of scene or prefab files?

7

In the most general sense, merging of either Scene or Prefab files ( or anything YAML-serialized, which is most of Unity’s data stores), just doesn’t reliably work.

You simply cannot count on it working, end of story.

If you really care about the data, the easiest way to do a manual merge is to duplicate the scene / prefab in Branch A, then merge and TAKE the Branch B version of the original, open them both and merge the changes in one into the other by hand.

1 Like
8

I agree 100%, and I’ll add that the reason for the fact that YAML merge doesn’t work comes from 2 facts:

  • there are some value changes because of float precision, so there may be more changes than what you did
  • sometimes entire blocks are moved all over the file, that confuse the merge algorithm to the point it will either tell you it’s lost, or it will just merge things the bad (very bad) way
1 Like
9

I see. So I guess the best way when working with multiple people is to avoid merge conflicts entirely. You mentionned “locking” files (with Git LFS I suppose). Have you tried it?

10

Unfortunately, locking file isn’t supported by GIT, it is a SVN feature.
The best you can do with GIT is to use very well define process, the problem is that it won’t be perfect as it will depend on people actually following the process correctly.
For example, when someone wants to modify a scene, he has to ask all the other members of the team if they are working on that scene, and he will work on it only when no other member of the team is working on it.

11

Two random options:

  • using a shared google spreadsheet that lists the scenes, and people mark it as “MINE” during the time they are working on it.

  • buy a bunch of yellow rubber ducks, write the name of each scene on it, and put it on a center table. People must have the appropriate scene duck before they can hack on it.

Neither of these ways will prevent parallel work merges, only merges in a given lineage.

12

The solution to your merge errors could be to create an additive scene manager. There are some youtube tutorial videos on that, although it can get very tricky to implement. I highly recommend doing it since you’ll learn a lot! The concept is to have a level that is built out of multiple scenes, so when you edit one scene and someone modifies something from another scene, the changes can “merge” and you can work together.
I’ve created a Unity tool that helps solve this issue, it has been recently published on the asset store!

2 Likes
13

Additive scenes are pretty awesome. Once you get used to them, you’ll never want to go back to one giant huge scene for stuff. I use additive loads all the time. Here’s my standard blurb of info:

Additive scene loading is one possible solution:

https://discussions.unity.com/t/820920/2
https://discussions.unity.com/t/820920/4

https://discussions.unity.com/t/824447/2

A multi-scene loader thingy:

https://pastebin.com/Vecczt5Q

My typical Scene Loader:

https://gist.github.com/kurtdekker/862da3bc22ee13aff61a7606ece6fdd3

Other notes on additive scene loading:

https://discussions.unity.com/t/805654/2

Timing of scene loading:

https://discussions.unity.com/t/813922/2

Also, if something exists only in one scene, DO NOT MAKE A PREFAB out of it. It’s a waste of time and needlessly splits your work between two files, the prefab and the scene, leading to many possible errors and edge cases.

Two similar examples of checking if everything is ready to go:

https://discussions.unity.com/t/840487/10

https://discussions.unity.com/t/851480/4

1 Like
14

(I cut out the quote to shorten)

I’m happy to see a like-minded developer, your route is great for those teams who have the resources for such! I’m mostly trying to advertise my tool (Instant Subscenes) for those who don’t have such resources or don’t want to go so much in-depth with scene management and focus more on the product and less on the engine’s missing features, although your links serve me well too!

15

Thank you for all your suggestions.
If you don’t mind @Gladyon and @Kurt-Dekker , could you walk me through the techniques you have personally tried to avoid merge conflicts with Git and how did it go?

16

I am working alone, so all I can give you is some untested ideas.

I would say that the best is that each scene has an ‘owner’.
When someone wants to modify a scene, he has to ask the owner, and he will decide when the modification can be done, that should be enough to avoid having several people modifying the same scene at the same time.

You can also use additive scenes and work the same with these, each additive scene would have a owner.
But I have no experience about these so I cannot give any more detail about how to use them.

In order to know who is the owner of a scene, you can call it ‘John_Level1’ for example, or ‘Level1_John’ depending on how you want them ordered.
It may be a problem if the people on the team often change, in which case you shouldn’t use names but a keyword instead.

I suggest that you keep the process simple and not time-consuming, or people won’t follow it.

1 Like
17

We are currently working on an open source merge tool, where you can interactivly resolve Scene and Prefab merge conflicts. It is still work in progress but might be helpful. Contributions welcome…