Unity Git LFS Workflow: 10 Essential Practices for Large Game Projects

A Unity project can start small.

A developer may begin with a few scripts, one environment, several prefabs, and a basic UI.

Months later, that same project can contain gigabytes of textures, FBX files, character animations, audio, PSD source files, gameplay scenes, plugins, and source code.

At that point, simply placing the entire project into a normal Git repository is not always enough.

Large binary assets can increase repository size quickly. Generated Unity folders can create unnecessary changes. Missing .meta files can break asset references. Two developers editing the same scene can create difficult merge conflicts.

A well-designed Unity Git LFS Workflow addresses these problems before they become production blockers.

The objective is not to put every Unity file into Git LFS. Instead, developers should separate normal source-controlled files from large binary assets, ignore generated data, preserve Unity metadata, and establish clear collaboration rules.

The following ten practices provide a practical foundation.

1. Understand What Git LFS Actually Does

Git is excellent at tracking text-based source files.

C# scripts, JSON configuration, shader source, and many text-based project files can be versioned efficiently because Git stores changes between revisions.

Large binary files behave differently.

Consider a 200 MB PSD file.

If an artist modifies that file several times and each revision is committed normally, repository history can grow substantially because Git cannot efficiently represent many types of binary changes the same way it handles text.

Git LFS addresses this by replacing selected files in the Git repository with small pointer files while storing the actual large-file content separately.

GitHub’s official Git LFS documentation explains that tracked file types are associated with LFS through .gitattributes.

Git LFS Does Not Replace Git

Git still manages:

• commit history
• branches
• merge requests
• source-code changes
• repository structure
• pointer files

Git LFS handles the large-file content associated with configured patterns.

Think of Git LFS as an extension to Git rather than an alternative version-control system.

2. Commit the Correct Unity Project Folders

One of the first mistakes teams make is committing the entire Unity project directory.

Unity generates many folders locally that should not normally be stored in source control.

A typical repository should include important project content such as:

Assets/
Packages/
ProjectSettings/

These folders contain game assets, package configuration, and project settings required to reconstruct the project.

Generated directories should generally be ignored.

The official GitHub Unity .gitignore template excludes folders such as:

Library/
Temp/
Obj/
Build/
Builds/
Logs/
UserSettings/

It also excludes other machine-specific or generated files.

Why Ignore the Library Folder?

Unity’s Library folder contains imported and generated project data.

It can become very large.

Another developer can regenerate it when opening the project.

Committing it usually creates unnecessary repository size and frequent machine-specific changes.

Keep the Repository Reproducible

A useful test is simple:

Can another authorized developer clone the repository, open it in the correct Unity version, allow Unity to import the assets, and obtain the intended project?

If the answer is no, the repository is probably missing required files or external dependencies.

3. Never Ignore Unity .meta Files

Unity .meta files are critical to asset identity.

Unity assigns assets GUIDs, and .meta files store important metadata associated with those assets.

If developers move or copy assets without their corresponding .meta files, references between scenes, prefabs, materials, scripts, and other assets can break.

Unity’s version-control documentation specifically provides a Visible meta files mode for external version-control systems.

What Should Be Committed?

If an asset is committed, its .meta file should normally be committed with it.

For example:

Assets/Vehicles/SportsCar.fbx
Assets/Vehicles/SportsCar.fbx.meta

Do not treat the .meta file as temporary clutter.

Common Failure Scenario

Imagine one developer imports a character model.

Another developer receives the FBX through Git but not the .meta file.

Unity may generate a new metadata file with a different GUID.

Prefabs or animation references that depended on the original GUID may then break.

This type of problem can be difficult to diagnose because the asset still appears inside the Project window.

4. Create a Proper Unity .gitignore Before the First Large Commit

A .gitignore tells Git which files and folders should not be tracked.

It should be configured before developers accidentally commit Unity-generated data.

GitHub maintains a public Unity .gitignore template that provides a strong starting point.

A simplified structure may include:

[Ll]ibrary/
[Tt]emp/
[Oo]bj/
[Bb]uild/
[Bb]uilds/
[Ll]ogs/
[Uu]ser[Ss]ettings/

.vs/
.gradle/

This is an illustrative subset, not a replacement for reviewing the current GitHub template.

Why Configure It Early?

Adding .gitignore after the Library folder has already been committed does not automatically remove that folder from existing repository history.

Teams may then need additional cleanup.

The safer approach is to configure the ignore rules before the initial project commit.

Review Project-Specific Folders

Some Unity projects generate additional temporary data from plugins, profiling tools, capture systems, or custom pipelines.

Review those folders before deciding whether they belong in source control.

Do not ignore a directory simply because it is large.

Determine whether the files are reproducible or required source assets.

5. Decide Which Unity Assets Belong in Git LFS

Not every Unity asset should be placed in LFS.

Text-based scripts and configuration files generally work well in ordinary Git.

Large binary files are better candidates.

Common Git LFS candidates may include:

*.psd
*.psb
*.fbx
*.blend
*.wav
*.mp4
*.mov
*.tga
*.exr

Projects may also choose to track large PNG, JPG, or audio assets through LFS depending on repository size and production workflow.

Do Not Copy Patterns Blindly

A mobile project with small compressed textures has different requirements from an AAA-style environment project containing multi-gigabyte source assets.

Before adding an extension to LFS, ask:

• Are these files large?
• Are they binary?
• Are they modified repeatedly?
• Do they significantly increase repository history?
• Does the hosting provider support the required LFS storage?

Track Files With Git LFS

For example:

git lfs track "*.psd"
git lfs track "*.fbx"
git lfs track "*.wav"

Git LFS updates .gitattributes.

Example:

*.psd filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text

The .gitattributes file itself should be committed.

GitHub explicitly recommends committing .gitattributes so fresh clones and collaborators receive the same LFS tracking configuration.

6. Add Git LFS Before Large Assets Enter Repository History

One of the most important workflow decisions is timing.

Git LFS works best when large files are configured before those assets are repeatedly committed into normal Git history.

Suppose a team commits a 500 MB source texture archive normally for six months.

Adding that extension to Git LFS later does not automatically erase every previous large revision from historical commits.

Repository cleanup may require history migration or rewriting.

Recommended Workflow

Before adding major art assets:

1. Install Git LFS.
2. Initialize it for the repository.
3. Define .gitattributes.
4. Commit the configuration.
5. Add the large assets.
6. Verify they are being tracked correctly.

Useful commands include:

git lfs install
git lfs track "*.psd"
git lfs track "*.fbx"
git add .gitattributes
git commit -m "Configure Git LFS for large Unity assets"

Verify Before Pushing

Use:

git lfs ls-files

to review files currently tracked through LFS.

A production repository should not assume that a file is managed through LFS simply because its extension appears in .gitattributes.

Verify the actual repository state.

7. Reduce Unity Scene and Prefab Merge Conflicts

Git LFS solves large-file storage problems.

It does not solve scene or prefab collaboration by itself.

Unity scenes and prefabs are serialized assets that multiple developers may edit simultaneously.

Two people changing the same scene can create merge conflicts.

Use UnityYAMLMerge

Unity includes UnityYAMLMerge, also called Smart Merge.

Unity’s current documentation explains that UnityYAMLMerge can semantically merge Unity scene, prefab, and .meta files and can be integrated with Git and other version-control tools.

For Git, Unity provides merge-tool configuration through .gitconfig or repository Git configuration.

The exact executable path depends on the installed Unity version and operating system.

Do Not Depend on Merge Tools Alone

Even a good merge tool cannot make every parallel edit safe.

Studios should reduce conflict risk through workflow.

For example:

• assign ownership of high-conflict scenes
• break large scenes into smaller additive sections where appropriate
• use prefabs for reusable content
• avoid multiple developers restructuring the same hierarchy simultaneously
• commit focused changes

Example

A large supermarket environment might separate:

• building shell
• shelf systems
• lighting
• customer spawn setup
• gameplay interaction objects

The exact architecture depends on the project, but smaller ownership boundaries can reduce the number of developers modifying the same serialized file.

8. Use Branches Without Creating Long-Lived Integration Problems

Git branches are useful for isolating work.

However, very long-lived branches can become difficult to merge in active Unity projects.

Imagine one developer changing the player controller for three weeks while another developer restructures prefabs that depend on it.

The eventual merge can become much more complicated than integrating smaller changes regularly.

Keep Changes Focused

A useful feature branch might contain:

feature/vehicle-upgrade-ui
fix/save-game-corruption
feature/new-supermarket-level

Avoid combining unrelated code, art, environment, and UI changes into one branch without a production reason.

Pull Before Starting Significant Work

Before modifying shared scenes or prefabs, update the local branch.

This reduces the chance of working for several hours on an outdated version of the same asset.

Commit Logical Units

A commit such as:

Fix product pickup collider references

is easier to review than:

updates

Clear commit history helps when teams need to identify when a bug was introduced.

9. Define an Asset Ownership Workflow for Artists and Developers

A strong Unity Git LFS Workflow is not only a technical configuration.

It also defines how people work.

3D artists may edit:

• FBX files
• textures
• Substance exports
• Photoshop files

Developers may edit:

• C# scripts
• prefabs
• ScriptableObjects
• scenes

Technical artists may work across both categories.

Identify High-Risk Shared Assets

Some files are difficult to merge.

Examples include:

• Photoshop files
• Blender files
• binary animation data
• certain imported assets

For those files, teams may need a simple ownership rule:

Only one person modifies the asset at a time.

Git LFS itself is primarily about storage. Locking support depends on the Git/LFS hosting and client workflow being used.

Keep Source Art Separate When Useful

A project may contain both final runtime assets and editable source files.

For example:

ArtSource/
    Vehicles/
        SportsCar.psd
        SportsCar.blend

Assets/
    Game/
        Vehicles/
            SportsCar.fbx
            SportsCar_Albedo.png

Whether source files belong inside the same repository depends on team size, storage limits, licensing, and delivery requirements.

For outsourced projects, this should be agreed before production.

GamePro Studio’s article on writing a game development brief discusses the importance of explicitly defining source-project and editable-asset deliverables before development begins.

10. Test the Repository Like a New Developer Would

A repository is not reliable simply because it works on the original developer’s computer.

Before a major milestone, test the source-control workflow from a clean environment.

Perform a Fresh Clone

Clone the repository into a new folder or test machine.

Confirm Git LFS downloads the required large assets.

Open the project using the intended Unity Editor version.

Allow Unity to rebuild the Library folder.

Verify the Project

Check:

• scripts compile
• scenes open correctly
• prefabs retain references
• textures and models are present
• packages resolve
• project settings are correct
• no critical assets are missing
• expected plugins are available

Generate a Test Build

A repository that opens correctly may still contain build-time problems.

Generate at least one representative build.

For teams already using CI/CD, the existing GamePro Studio Unity Build Automation workflow provides complementary guidance on reproducible builds and source revision tracking.

Combine With QA

Repository validation should also connect with project testing.

The GamePro Studio Unity Game QA Checklist covers gameplay testing, progression, UI, final-build verification, and client handoff.

A reliable source repository and a reliable gameplay build solve different problems.

Both matter.

---

Practical Example: Git LFS for a 3D Racing Game

Consider a hypothetical Unity racing game developed by a small team.

The project contains:

• C# vehicle systems
• 20 vehicle models
• high-resolution textures
• source PSD files
• multiple tracks
• environment FBX files
• audio
• UI
• prefabs
• gameplay scenes

Stage 1: Create the Repository

The team initializes Git at the Unity project root.

A current Unity .gitignore is added before the first major commit.

Stage 2: Preserve Unity Metadata

All project assets and matching .meta files are tracked.

Generated folders such as Library remain ignored.

Stage 3: Configure LFS

Large file types such as PSD, FBX, WAV, and selected texture formats are assigned to Git LFS.

The .gitattributes file is committed.

Stage 4: Commit the Core Project

Scripts, project configuration, package files, scenes, prefabs, and selected assets are committed.

Stage 5: Separate Work

Developers use focused branches.

Artists coordinate ownership of large binary assets.

Stage 6: Configure Smart Merge

UnityYAMLMerge is configured for serialized Unity scene and prefab conflicts.

Stage 7: Validate With a Fresh Clone

Another machine clones the repository, downloads the LFS objects, opens the project, and creates a test build.

Stage 8: Document the Workflow

The repository README explains:

• Unity version
• LFS requirement
• project setup
• branch conventions
• build instructions
• required packages

This is an illustrative workflow and not a claim about a specific GamePro Studio client project.

---

Common Unity Git LFS Workflow Mistakes

Committing the Library Folder

The Library folder is generated locally and can become extremely large.

Ignoring it should normally happen before the first major commit.

Ignoring .meta Files

This can break Unity GUID references and cause scenes, prefabs, materials, and scripts to lose asset relationships.

Sending Every File Through Git LFS

Git LFS should target appropriate large binary files.

Small scripts and normal text configuration do not need LFS merely because LFS is available.

Configuring LFS Too Late

If large binary files already exist throughout Git history, switching future revisions to LFS may not solve historical repository growth.

Forgetting .gitattributes

Without the committed .gitattributes configuration, other collaborators may not receive the intended file-tracking rules.

Letting Multiple Artists Edit the Same Binary Asset

Binary source files may not merge cleanly.

Use ownership, locking where supported, or communication rules.

Using One Giant Unity Scene

Large serialized scenes increase conflict risk when multiple developers edit them.

Modular scene and prefab organization can make collaboration easier.

Never Testing a Fresh Clone

A project can appear healthy on one machine while depending on untracked local files.

Fresh-clone testing exposes those dependencies.

---

Unity Git LFS Workflow Checklist

Area	Recommended Practice
Repository Root	Unity project root
Core Project Files	Track Assets, Packages, ProjectSettings
Generated Files	Ignore Library, Temp, Obj, Builds, Logs
Metadata	Commit .meta files
Large Assets	Track selected binary types with Git LFS
LFS Configuration	Commit .gitattributes
Merge Strategy	Configure UnityYAMLMerge
Branches	Keep focused and regularly integrated
Binary Ownership	Coordinate non-mergeable assets
Verification	Perform clean clone and test build
Documentation	Record Unity version and project setup

---

Conclusion

A reliable Unity Git LFS Workflow gives development teams a cleaner way to manage source code, large art assets, project settings, and collaborative changes.

The most important practices are straightforward:

Track the Unity files that actually define the project. Ignore generated data. Preserve .meta files. Use Git LFS selectively for large binary assets. Commit .gitattributes. Configure a merge strategy for Unity’s serialized files. And regularly verify the project from a fresh clone.

Version control should make a project easier to recover, transfer, review, and continue developing.

For studios working on mobile, PC, VR, or large 3D Unity projects, repository architecture becomes increasingly important as the codebase and asset library grow.

GamePro Studio provides Unity development, 3D art, source-code customization, optimization, porting, and cross-platform production services for projects that require structured development and long-term maintainability.

Frequently Asked Questions