Unity Pull Request Review
How to Review Unity Scenes and Prefabs in Pull Requests
A Unity pull request should not approve scene or prefab files from a raw YAML diff alone. Review the branch against its merge base, identify object and hierarchy changes, resolve references and prefab context, validate the result in Unity, and attach automated evidence for structural risks.
Start with the complete asset scope
List every changed Unity asset and group related files before opening individual diffs:
git diff --name-status origin/main...HEAD -- \
'Assets/*.unity' 'Assets/*.prefab' 'Assets/*.asset' \
'Assets/*.mat' 'Assets/*.meta'Review scenes and prefabs together with their referenced materials, ScriptableObjects, scripts, and meta files. A one-line GUID change can depend on a new or moved asset elsewhere in the pull request.
What the author should provide
- A plain-language summary of intended scene and prefab behavior changes.
- The affected levels, prefabs, systems, and test paths.
- Screenshots or video for visible level/layout changes when useful.
- A semantic asset report for large or non-obvious serialized changes.
- Disclosure of reserialization, Unity upgrades, mass imports, or generated churn.
- Validation results and any known warnings.
The description should help a reviewer distinguish intentional content from editor noise before spending time on details.
Review in a stable order
- Asset list. Confirm that only intended files changed and matching meta files are present.
- Structure. Review GameObject additions, removals, hierarchy moves, child/root order, and component ownership.
- Properties. Inspect transforms, active state, serialized fields, material settings, and other values.
- Prefab context. Separate source prefab changes, nested links, and instance overrides.
- References. Resolve changed GUIDs and fileIDs to understandable targets.
- Runtime impact. Check scripts, tests, builds, and representative scenes in Unity.
Create a reviewable semantic report
MergeSight pull-request asset review can compare the target branch or merge-base commit with the feature branch, filter changed Unity assets, and export Markdown or JSON summaries. Reviewers can inspect object, component, property, hierarchy, override, material, GUID, fileID, and reference changes without reconstructing the complete YAML document.
Keep the raw diff available for exact evidence. The semantic report should organize it, not hide it.
Risk-based review depth
| Risk | Examples | Required review |
|---|---|---|
| Low | Isolated scalar value, obvious material adjustment | Semantic diff + targeted Unity check. |
| Medium | New component, prefab override, several linked assets | Domain reviewer + reference/ownership validation. |
| High | Scene hierarchy restructure, nested prefab source change, mass reserialization | Dedicated scene/prefab owner, Unity validation, and CI artifacts. |
| Blocking | Conflict markers, missing scripts, dangling references, unexplained deletion | Fix before approval. |
What CI should contribute
- Fail on unresolved conflict markers in supported Unity text assets.
- Detect assets that cannot be parsed when text serialization is expected.
- Validate missing scripts, dangling references, hierarchy, and ownership where tooling supports it.
- Upload Markdown or JSON asset reports as workflow artifacts.
- Run Unity import, tests, or builds at the depth appropriate to the repository.
Automation should report objective structural risks. It should not approve level design intent or silently choose one side of an ambiguous conflict.
Approval checklist
- The pull request explains why each high-impact asset changed.
- The semantic comparison matches the stated intent.
- References, prefab links, overrides, hierarchy, and component ownership are valid.
- The relevant assets open in the project's Unity version.
- No unrelated reserialization or generated churn remains.
- Required asset owners and CI checks have approved the branch.
FAQ
Can GitHub review Unity scene and prefab files?
GitHub can show their text changes, but raw YAML does not explain hierarchy, object ownership, prefab overrides, or resolved references. Add semantic review and Unity validation for reliable approval.
What should a Unity asset pull request include?
Include intended behavior, affected assets, semantic change evidence, related meta and dependency files, screenshots when useful, validation results, and disclosure of generated or reserialized churn.
Who should review Unity scene changes?
Use a relevant scene or level owner for high-impact hierarchy and layout changes, plus technical reviewers when scripts, references, prefab architecture, or automation are affected.
Can MergeSight export reports for pull requests?
Yes. MergeSight Review Mode can export Markdown and JSON summaries of supported Unity asset changes for reviewers and automation.
Summary
Review the branch scope
Start from the merge base and include every related Unity and meta file.
Explain semantic impact
Translate YAML into hierarchy, ownership, properties, overrides, and references.
Require evidence
Combine domain approval, Unity validation, and objective CI checks.
A strong Unity pull request lets reviewers understand asset intent without trusting either raw YAML noise or an unexplained automatic result.
Next step
Automate the reporting layer with semantic Unity asset diff reports for pull requests.