Unity Scene Files Disappeared After Using Git and GitHub

[unity_9E33B18309FD6B2A5AD3]

I need help with a serious problem involving my Unity project.

I was using Terminal to upload my Unity project to GitHub. During the process, I used Git commands including push, rebase, and commands related to merge conflicts. After this process, I discovered that some of my work inside my Unity scenes had disappeared.

The files and scene changes are very important to me, and I am worried that my work may have been overwritten or deleted during the Git process.

Is there any way to recover the missing Unity scene data? Could the previous version still exist in Git history, GitHub commits, or somewhere on my local Mac?

I would really appreciate any advice on how I can recover my lost work. Thank you.

[bugfinders]

look through git, and yes, its kinda on your hard disk but not in the way you potentially want. Normally git does not delete files unless you do things like check out a commit before it exists, or delete them yourself, etc.

[Kurt-Dekker]

The good news is that as soon as you stage a file for committing in git, it is copied and compressed, even if you don’t commit it. Recovering files from git is FAR beyond anything someone could type in this box, but I suggest that you:

a) IMMEDIATELY make a full copy of everything, including the .git folder of your project
b) start investigating how to recover files in git, perhaps using a chatbot system such as Claude Code

Here’s more:

Lost progress / project / work / stuff disappeared in Unity.

This article is to help you when you have lost significant progress or work in your Unity project.

It is designed to give you avenues of discovery and investigation.

It is NOT a guarantee of restoring your lost work. It is NOT a substitute for proper IT / Data security procedures.

To decide which parts are applicable to you, look for major bolded headings.

EVERYTHING IS GONE, YOU CANNOT OPEN THE PROJECT

Your project probably is still on your computer. Try a computer-wide search for some unique filenames that you know are in the project you think is gone.

To start your search, one common file to all Unity projects is named ProjectSettings.asset

Some things that might have happened:

• you are not opening the project that you think you are
• you are in the correct project but not opening the same scene you had open before
• you dragged the project (or part of it) into the trash (intentionally or inadvertently)
• you moved the project (or part of it) somewhere else (intentionally or inadvertently)
• an overly-aggressive antivirus solution quarantined it because it saw code being compiled in there
• you’re using a directory sync like OneDrive or Dropbox… NEVER USE THESE SERVICES WITH UNITY!
• something else?

As I said, it’s probably still all on your system to be found if you look in the right places.

A typical Unity project will have at a minimum the following folders:

Assets\
ProjectSettings\
Packages\

EVERYTHING IS PRESENT BUT MY SCENE WINDOW IS BLANK

Close Unity and make a full project backup RIGHT NOW. Do not do ANYTHING else until you back it up 100%.

Ideally copy that backup to another computer, or back it up to another external hard drive entirely. This is just basic data processing best practices during data recovery operations.

If you can see all the files and folders of your project, make sure you are opening the scene file you were working in.

Once you have opened the scene, look in the hierarchy window, select an object and move the mouse over the Scene window and press F to focus that object.

Additional notes:

• ALWAYS use proper industrial grade source control (see below)
• NEVER use Dropbox or any file sync mechanism in Unity.
• NEVER move files within your project, except by doing it within Unity
• ALWAYS be sure you are fully backed up before upgrading Unity

SCRIPTS OR ASSETS ARE MISSING OR BLANK

ALWAYS move all Unity assets by using the Unity Editor. Any other way risks disconnecting the GUID in the meta file from the original file, and this will result in all connections to that asset being broken.

Some info about Missing script warnings, broken prefabs, GUIDs, renaming GUIDs, etc:

Problem with Git and missing scripts

If you delete a script and recreate it, Unity will produce a new .meta file, with a randomly chosen guid. The guid inside that metafile is what “connects” the script to the prefabs / scenes / assets. Here’s an example, with the guid fortuitously underlined with a red squiggle: [7024801--832060--Screen Shot 2021-04-10 at 9.13.40 AM.png] What you need to do is look in git history and find out what the original guid was for that file (the one you deleted when you deleted the script), then modif…

Scriptable Object data not read after loading editor.

The linkage between a scriptable object instance and its script is twofold. For one it is the GUID contained in the .meta file for the script, but the other requirement is the class and file naming requirement as you list above. For instance, this is my StartingShips scriptable object: (StartingShips.asset, NOT the meta file) %YAML 1.1 %TAG !u! tag:unity3d.com,2011: --- !u!114 &11400000 MonoBehaviour: m_ObjectHideFlags: 0 m_PrefabParentObject: {fileID: 0} m_PrefabInternal: {fileID: 0} …

Scriptable Object data not read after loading editor.

If you rename the class from within visual studio, the currently infuriating state of that function (for actually the past decade, going back to Monobehavior) is that it renames the .cs file but does NOT rename the .cs.meta file. Therefore, Unity throws out your original GUID, which you MAY have already used, and creates a new one when it creates the new .meta file. It is the single most Fisher-Price non-professional feature there is in Unity. It is probably responsible for more bugs and lost …

EVERYTHING in Unity is connected to the above GUID, which is stored ONLY in the metafile, and hence why the metafiles ALWAYS MUST be source-controlled.

When Renaming: It is super-easy to inadvertently change the GUID by renaming outside of Unity. Don’t do that. Instead:

• close Visual Studio (important!)
• rename the file(s) in Unity
• in Unity do Assets → Open C# Project to reopen Visual Studio
• now rename the actual classes, and MAKE SURE THE FILE NAMES DO NOT CHANGE!

If you are NOT using source control while you do this, renaming files is an EXTREMELY dangerous process. Use source control at all times so that you can trivially revert if you miss a critical step and damage your project.

REMEMBER: the main problem with causing this type of renaming damage is that it does NOT get caught by the compiler or by Unity until you actually run that piece of code, and it might be weeks later. And when it is caught, it just fails, no clues, no way to track it back unless you use source control always.

UNITY CRASHES / FREEZES WHEN I OPEN MY PROJECT

You must isolate if there is something wrong with your Unity installation, something wrong with your project, or perhaps just a corrupted import or asset database.

First, ALWAYS back your project up. Then try deleting the Library/ and Temp/ folders that are within your project, the directories that are peers to the Assets/ and ProjectSettings/ folders.

If that doesn’t work it is time to bisect. Make a new empty project and get Unity to open that. If you cannot then it is time to fix your Unity installation, either by fully reinstalling or verifying it with the hub.

Once you have an empty project open, begin copying over your project. Try the entire thing. If it crashes, try half of the project, then the other half, etc.

As always, if you’re using Windows, another thing to try is to simply reboot the system. This often fixes typical Windows issues related to locked files and locked directories.

Antivirus systems can also cause issues with Unity, so make sure your antivirus is configured correctly.

ISSUES RELATED TO UPGRADING PROJECTS (eg, changing to a higher Unity version)

Upgrading to a later version of Unity is a one-way process. Any project that has been updated should NEVER be reverted to an earlier version of Unity because this is expressly not supported by Unity. Doing so exposes your project to internal inconsistencies and breakage that may actually be impossible to repair.

If you want to upgrade to a newer version of Unity, do not even consider it until you have placed your project fully under proper source control. This goes double or triple for non-LTS (Tech Stream) versions of Unity3D, which can be extremely unstable compared with LTS.

Once you have source-controlled your project then you may attempt a Unity upgrade. Immediately after any attempted upgrade you should try to view as much of your project as possible, with a mind to looking for broken animations or materials or any other scripting errors or runtime issues.

After an upgrade you should ALWAYS build to all targets you contemplate supporting: iOS and Android can be particularly finicky, and of course any third party libraries you use must also “play nice” with the new version of Unity. Since you didn’t write the third party library, it is up to you to vet it against the new version to make sure it still works.

If there are issues in your testing after upgrading Unity, ABANDON the upgrade, revert your project in source control and be back where you were pre-upgrade with the earlier version of Unity.

Obviously the less you test after the upgrade the more chance you will have of an undiscovered critical issue.

This risk of upgrading is entirely on you and must be considered whenever you contemplate a Unity version upgrade.

Do not upgrade “just for fun” or you may become very unhappy.

ISSUES RELATED TO GOING BACK OR UNDOING BREAKING CHANGES TO YOUR WORK

Keep in mind that Unity does NOT back your files up. That’s on YOU.

Use either version control (see below) or else make your own backups.

PROPERLY CONFIGURING AND USING ENTERPRISE SOURCE CONTROL

I’m sorry you’ve had this issue. Please consider using proper industrial-grade enterprise-qualified source control in order to guard and protect your hard-earned work.

Personally I use git (completely outside of Unity) because it is free and there are tons of tutorials out there to help you set it up as well as free places to host your repo (BitBucket, Github, Gitlab, etc.).

You can also push git repositories to other drives: thumb drives, USB drives, network drives, etc., effectively putting a complete copy of the repository there.

As far as configuring Unity to play nice with git, keep this in mind:

Prefab links keep getting dumped on Git pull

There really isn’t any fix because git works perfectly with Unity when configured properly. Best practices involve saving your work and closing Unity before using git. But if you understand how Unity does and does not flush changes to disk (or at least ALWAYS do a save-project), you can get away with leaving Unity open. The only thing linking EVERYTHING together in Unity is the GUID assigned to a script or asset. Name is irrelevant. Only the GUID connects it. This GUID is in the meta file. I…

I usually make a separate repository for each game, but I have some repositories with a bunch of smaller test games.

Here is how I use git in one of my games, Jetpack Kurt:

2 steps backwards

Yeah, what Praetor said is it… Debug.Log is your friend, and also since this is animation related, you can open up the Animator window when you expect the animations to go, and actually visually see where the state machine is, see which state it thinks it is in. You can combine this with Debug.Log() output at the locations where you set the animations to be what you think they should be, and that should lead you to some intel. I highly recommend setting up git source control. It really plays ni…

Using fine-grained source control as you work to refine your engineering:

When to make a separate object or class/script? Help me think like a programmer! (Example in text.)

This is a reasonable initial approach. The problem is you have listed the parts, but you haven’t really listed how they interact, and even if you did, it’s still sorta up to you how to organize it. Only YOU will know how to organize it, and the only way you can tell is to do the work. I recommend this: first, develop ALWAYS with source control (such as git), and every time you get even the slightest thing working, commit those changes with good commit messages. Then move to the next thing, c…

Share/Sharing source code between projects:

Your techniques to share code between projects?

I have found that bundling your own code into DLLs only serves to slow down your workflow. I base this on several years of experience dealing with other teams well-intentioned packaging mishaps. With games, it is almost always useful to reach into library code, make a temporary tweak to isolate a problem, and then revert it. With DLLs this is impossible, making workflow harder and more brittle. I prefer to share source code at the C# level. That way I can reach into libraries trivially and inje…

Setting up an appropriate .gitignore file for Unity3D:

Removing IL2CPP_cache from Project

Not sure what you are “auto generating” with… I usually start from one of my other projects, or a gitignore example online, and reason about all the parts inside it, and start from there. Like any other configuration change, after you make it, pay attention for a while to make sure it is what you want. You can always clone the repo somewhere else to verify that the correct files are being tracked. Doing so to a brand-new computer is the acid test to make sure you can still build the project. …

Generally the ONLY folders you should ever source control are:

Assets/
ProjectSettings/
Packages/

NEVER source control Library/ or Temp/ or Logs/
NEVER source control anything from Visual Studio (.vs, .csproj, none of that noise)
ALWAYS source control the .meta files for your entire project (see setup links above)

Setting git up with Unity (includes above .gitignore concepts):

How to Git with Unity

It is only simple economics that you must expend as much effort into backing it up as you feel the work is worth in the first place. Digital storage is so unbelievably cheap today that you can buy gigabytes of flash drive storage for about the price of a cup of coffee. It’s simply ridiculous not to back up.

If you plan on joining the software industry, you will be required and expected to know how to use source control.

Source control does require learning, but there are TONS of tutorials and courses and online reference.

You should strive to use source control as confidently as you use your file/folder system.

“Use source control or you will be really sad sooner or later.” - StarManta on the Unity3D forum boards

[slitherine_paul]

Since you had merge conflicts that means you must have tried to merge branches with different changes. Git has a problem with Unity .meta files (which is what Unity uses to manage links between its assets.) There is more discussion of the issue here:

GIT conflict markers in .meta files (usually guid conflicts) [SourceTree]

I have a repro. At least, I have a repro for git detecting a delete and an add as a move and creating conflicts. create a new Unity project and connect to GitHub add a single asset, e.g. a Material commit changes make a new branch: branch1 delete the asset and a new different one, e.g. an Animation clip commit changes Notice here that when you commit, SourceTree will show the meta file as renamed rather than deleted / added. [image] create a new branch from main: branch2 delete the first a…

The issue is due to most .meta files being so similar that git treats them as files more likely moved from one location to another rather than one deleted and another added. And this leads to conflicts at merge time. You can prevent this behaviour in git (at least locally) with the following git configuration:

git config merge.renames false

I would recommend altering this default setting for anyone using Unity with git.