How to avoid merge conflicts git?

Unity Engine
1

What would you do in the following situation:

I am working on a level for a few hours and someone else from the team, while I am working, goes in and makes a bunch of changes to the level. They push the changes unknown to me. I go to push my changes but receive a bunch of merge conflicts. I keep having this problem.

Is there a best practice for avoiding merge conflicts? How do you resolve these?

Thanks!

2

Keep everyone in the loop as to who is working on what, to avoid stepping on other people’s toes. If you have large scenes in which multiple people need to work on them at the same time, consider splitting them up into smaller scenes which you additively load, so they can be worked on at the same time by different people without conflicts.

3

This. This a thousand times over. My typical project when it goes to play loads:

  • a scene for the UI (sometimes a few scenes for this)
  • a scene for the player control
  • a scene to drive the enemy
  • content scenes (at least one, sometimes multiple, such as one for lighting, etc.)
  • sometimes a debug control scene in the editor

The Player and Enemy managers just hang around waiting for spawn points to appear in scene (checking each frame until they do), then when the level content has finished loading, off it goes.

This way you have far less chance of a conflict editing a scene.

And if you have a prefab that is used in only one scene, DO NOT USE A PREFAB! If it never has to appear in more than one scene, you’re just increasing the surface area where you can cause errors by having two files (the prefab and the one scene that uses it) have to remain in perfect synchrony. ONLY use prefabs if an object is going to be referenced in multiple scenes, or loaded at runtime.

1 Like
4

out of interest, what should i use instead of a prefab if i want to, say, have 2 devs working on different controllers in the same scene?

there is only one of each controller, but not using a prefab would result in unresolvable merge conflicts

5

That is an excellent use of actually making prefabs out of those controllers, despite it only appearing in one scene.

CRITICAL: make sure that once the prefab is made, NO FURTHER CHANGES are made to the parts of the prefab within the scene, because obviously those would split the “truth” between the scene and the prefab.

Serialized properties in Unity are initialized as a cascade of possible values, each subsequent value (if present) overwriting the previous value:

  • what the class constructor makes (either default(T) or else field initializers)

  • what is saved with the prefab <---------- try to do 100% of the work here

  • what is saved with the prefab override(s)/variant(s) ← or here if you use variants!

  • what is saved in the scene and not applied to the prefab <------------- this is often mistakenly where work gets committed… don’t do that.

  • what is changed in Awake(), Start(), or even later etc.

Make sure you only capture valid work at ONE of the above levels, or if necessary, at levels that you specifically understand in your use case. Otherwise errors will seem very mysterious.

At the end of the day it comes down to having acute awareness of where your work is being saved. Unity does NOT make knowing this easy, but it can be known with some extra effort, and it CAN be tracked via source control for further clarity.