How to Remove the Library Folder from Your Unity Git Repository

July 2026 · 4 min read · by the unity.gitignore team

It happens to almost everyone once: you create a Unity project, run git add . before adding a gitignore, and suddenly your repository contains a multi-gigabyte Library folder. Pushes take forever, your host complains about repo size, and teammates get merge conflicts in files nobody ever opened. Here's how to fix it cleanly.

Why this happens

A .gitignore file only prevents untracked files from being added. Once a file has been committed, Git keeps tracking it — even if you add an ignore rule afterwards. So the fix always has two parts: add the ignore rule, then tell Git to stop tracking the files it already knows about.

Step 1: Add a proper gitignore first

Before removing anything, make sure your project root has a complete Unity gitignore — you can download ours from the home page. Without this, the folder would just get re-added on your next commit.

Step 2: Untrack the folder (without deleting it)

The key command is git rm with the --cached flag, which removes files from Git's index but leaves them on your disk:

# untrack the generated folders, keep them locally
git rm -r --cached Library
git rm -r --cached Temp
git rm -r --cached Obj
git rm -r --cached Logs

Don't panic when the terminal prints hundreds of "rm" lines — nothing is being deleted from your computer. Git is only forgetting about the files.

Step 3: Commit the cleanup

git add .gitignore
git commit -m "Remove generated folders from version control"

From this commit forward, the Library folder is invisible to Git. Teammates who pull this commit will see the folder disappear from tracking, but Unity will simply regenerate their local copy on next launch — that's expected and harmless.

Optional: shrinking the history too

The steps above stop future bloat, but the old Library files still live in your Git history, so clones remain heavy. If the repo is young, the easiest fix is starting a fresh repository. For established projects, tools like git filter-repo or BFG Repo-Cleaner can strip a folder from all past commits — coordinate with your whole team first, because this rewrites history and everyone must re-clone. We cover this in detail in 7 ways to reduce your Unity repo size.

Unity Git LFS Setup: The Complete Guide for Large Assets

July 2026 · 6 min read · by the unity.gitignore team

Git was designed for source code — small text files that diff beautifully. Game projects are the opposite: full of textures, audio, video, and 3D models that Git stores as opaque blobs, keeping every version of every file forever. Git LFS (Large File Storage) solves this by storing big binaries outside your normal Git history, replacing them with tiny pointer files.

When do you actually need LFS?

A simple rule: if your project contains more than a handful of files over ~10 MB, or your art content will be revised often, set up LFS before your first commit. Migrating an existing repo to LFS is possible, but doing it from day one is painless.

Step 1: Install Git LFS

# Windows (with winget) 
winget install GitHub.GitLFS

# macOS (with Homebrew)
brew install git-lfs

# then, once per machine:
git lfs install

Step 2: Track your heavy file types

Run these from your project root. Each command adds a rule to a .gitattributes file:

# textures & images
git lfs track "*.png" "*.jpg" "*.tga" "*.psd" "*.exr"

# audio & video
git lfs track "*.wav" "*.mp3" "*.ogg" "*.mp4"

# 3D models & animation
git lfs track "*.fbx" "*.obj" "*.blend"

# misc binary
git lfs track "*.ttf" "*.otf" "*.dll" "*.a"

Step 3: Commit the .gitattributes file

git add .gitattributes
git commit -m "Configure Git LFS tracking"

This file is the LFS equivalent of your gitignore — commit it and keep it at the repo root so every teammate uses the same rules automatically.

Step 4: Work normally

That's the beautiful part: from here, nothing changes in your daily workflow. git add, commit, and push behave exactly the same — LFS silently intercepts tracked file types and stores them efficiently.

Things to watch out for

• Hosting quotas: GitHub, GitLab, and Bitbucket all have separate storage/bandwidth quotas for LFS. Check your plan's limits for large teams.
• Files added before tracking: if a .png was committed before you ran lfs track, it stays in normal history. Use git lfs migrate import --include="*.png" to convert old commits (rewrites history — coordinate with your team).
• Cloning: teammates must have LFS installed before cloning, or they'll see pointer files instead of assets. It's a one-time git lfs install.

Unity Smart Merge: Stop Losing Work to Scene & Prefab Conflicts

June 2026 · 5 min read · by the unity.gitignore team

The most feared message in any Unity team: "CONFLICT (content): Merge conflict in Assets/Scenes/Main.unity". Scene and prefab files are YAML documents thousands of lines long, and hand-merging them is a nightmare. The good news: Unity ships with a dedicated merge tool — UnityYAMLMerge, also called Smart Merge — that resolves most scene conflicts automatically.

Prerequisite: force text serialization

Smart Merge only works if your scenes are stored as text. In Unity, open Edit → Project Settings → Editor and set Asset Serialization Mode to Force Text. (New projects default to this, but verify it — binary scenes cannot be merged at all.)

Configure Git to use UnityYAMLMerge

Add this to your .gitconfig (global) or the repo's .git/config, adjusting the path to your Unity version:

[merge]
    tool = unityyamlmerge

[mergetool "unityyamlmerge"]
    trustExitCode = false
    cmd = 'C:\\Program Files\\Unity\\Hub\\Editor\\<VERSION>\\Editor\\Data\\Tools\\UnityYAMLMerge.exe' merge -p "$BASE" "$REMOTE" "$LOCAL" "$MERGED"

On macOS the tool lives inside the Unity app bundle at Unity.app/Contents/Tools/UnityYAMLMerge.

Using it when a conflict happens

# after git pull / merge reports a conflict:
git mergetool

# then verify the scene opens correctly in Unity, and:
git add Assets/Scenes/Main.unity
git commit

UnityYAMLMerge understands the structure of scene files. If you moved a light and your teammate added a new enemy prefab, it merges both changes cleanly — something a line-based text merge would mangle.

When Smart Merge can't help

If two people edit the same property of the same object (say, both move the same platform), no tool can guess who's right — it will fall back and ask you. That's why healthy Unity teams also use a simple social rule: one scene, one owner at a time. Break big levels into multiple additively-loaded scenes or prefabs so people rarely touch the same file. More on this in our branching strategy guide.

Git vs Unity Version Control: Which Should Your Team Use?

June 2026 · 7 min read · by the unity.gitignore team

Unity offers its own version control system — Unity Version Control (formerly Plastic SCM) — as part of Unity DevOps. Meanwhile, Git remains the world's default. Which one fits your team? Here's an honest breakdown with no fanboying either way.

Where Git wins

• Ecosystem and skills. Every programmer already knows Git. CI/CD pipelines, code review tools, GitHub Actions, issue trackers — everything integrates with Git first.
• Free hosting options. GitHub and GitLab offer generous free private repos; small teams can operate at zero cost (watch LFS quotas).
• Portability. Your history is yours. Moving hosts is trivial, and nothing ties you to one vendor's pricing.
• Open toolchain. Thousands of GUI clients, hooks, and automation tools exist for Git.

Where Unity Version Control wins

• Built for big binaries. No LFS bolt-on needed — large files are first-class citizens. Artists can work with partial workspaces and don't need to download the whole project.
• Artist-friendly UI. Gluon, its simplified client, lets non-technical team members check files in and out without learning commands or concepts like staging.
• File locking. Native, reliable locking prevents two people from editing the same binary scene in the first place — often better than merging after the fact.
• Unity integration. Version control operations appear directly inside the Unity Editor.

Cost considerations

Unity Version Control's free tier is limited (a small number of users and storage); beyond that you pay per user per month plus storage. Git itself is free, though realistic Unity teams pay something for LFS storage on GitHub/GitLab or self-host. For programmer-heavy teams, Git usually ends up cheaper; for large art teams, UVC's pricing can be justified by saved friction.

Our honest recommendation

• Solo devs and small teams (1–5): Git + LFS + a good gitignore. Free, universal, and this whole site exists to make it easy.
• Programmer-led teams: Git — your existing workflow, reviews, and CI carry over.
• Art-heavy teams (10+ with many non-programmers): seriously evaluate Unity Version Control. Locking and partial workspaces genuinely reduce pain at that scale.

The Best Git Branching Strategy for Unity Game Teams

May 2026 · 6 min read · by the unity.gitignore team

Branching advice written for web developers doesn't survive contact with a game project. Unity repos are full of binary and semi-binary files that don't merge, which changes the math on long-lived branches. Here's a strategy that respects that reality.

The core principle: short-lived branches

The longer a branch lives, the more scenes and prefabs drift apart from main, and the uglier the eventual merge. So the golden rule for Unity teams: branch small, merge fast. A feature branch should live days, not weeks.

A structure that works

• main — always opens in Unity without errors. Protected; changes arrive only via reviewed pull requests.
• feature/* — one branch per task (e.g. feature/enemy-ai, feature/main-menu-ui). Created from main, merged back within a few days.
• release/* — cut when preparing a build for QA or a platform submission; only fixes land here, then it merges back to main with a version tag.

That's it. Avoid a permanent develop branch unless you have a dedicated build/QA process that demands it — every extra long-lived branch multiplies scene-merge pain.

Three Unity-specific rules

1. Partition work by scene and prefab

Merge tools help, but the best conflict is the one that never happens. Break levels into multiple additively-loaded scenes, push shared objects into prefabs, and assign ownership so two people rarely edit the same file in parallel branches.

2. Rebase small, merge big

Keep feature branches current by rebasing onto main daily while the branch is private. Once a branch is shared or contains gnarly scene changes, prefer merge commits — rebasing shared history creates chaos.

3. Pull before you open Unity

A surprisingly effective habit: sync first thing, then work. It shrinks the window in which two people unknowingly edit the same asset.

What about locking?

Git has no native file locking, but Git LFS supports lockable files: mark scene files as lockable in .gitattributes and teammates can claim a lock with git lfs lock Assets/Scenes/Main.unity. It's opt-in discipline rather than enforcement, but for small teams it's usually enough.

7 Proven Ways to Reduce Your Unity Git Repository Size

May 2026 · 5 min read · by the unity.gitignore team

Is your Unity repo measured in gigabytes, cloning slower every month? Repository bloat creeps in quietly and compounds. Here are seven fixes, ordered from easiest to most drastic.

1. Verify your gitignore is actually working

Run git ls-files | head -50 and scan the output. If you see anything from Library/, Temp/, or *.csproj, your ignore rules came too late — untrack them with git rm -r --cached as shown in our Library-folder guide.

2. Move binaries to Git LFS

The single biggest win for most projects. New files: just set up tracking. Existing history: convert with git lfs migrate import --include="*.png,*.fbx,*.wav" --everything — this rewrites history, so the whole team must re-clone afterwards.

3. Find what's actually big

Don't guess — measure. This lists your largest objects in history:

git rev-list --objects --all |
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' |
  sort -k3 -n -r | head -20

4. Strip dead weight from history

Found a 900 MB video someone committed in 2024 and deleted a week later? It still lives in history. git filter-repo --path path/to/file --invert-paths removes it from every commit. Again: history rewrite, team coordination required.

5. Delete stale branches and tags

Old branches pin old objects in memory. Merge or delete branches that shipped months ago, then let your host run garbage collection (or run git gc --aggressive --prune=now on a self-hosted repo).

6. Question what belongs in the repo at all

Raw footage, PSD masters with 50 layers, recorded gameplay videos, build outputs — do these need version control, or just storage? Cloud drives and asset servers are cheaper than Git history. Keep the repo for things that need versioning.

7. The nuclear option: fresh start

For a project early in development with hopeless history, sometimes honest triage wins: copy the working tree, create a new repo with a correct gitignore and LFS from day one, and archive the old repo read-only. One afternoon of pain, years of cleanliness.

Unity .meta Files Explained: Why They Break Your Project

April 2026 · 4 min read · by the unity.gitignore team

Open any Unity project's Assets folder in a file explorer and you'll see a shadow: for every file and folder, a matching .meta file. New developers often see them as clutter — and ignoring or deleting them is the fastest way to break a shared project. Here's what they actually do.

What's inside a .meta file

Each .meta file is a small YAML document with two crucial jobs:

• The GUID. A unique identifier for the asset. When a script references a texture, or a scene references a prefab, Unity stores the connection by GUID — never by filename or path.
• Import settings. Everything you set in the Inspector's import panel: texture compression, sprite mode, audio quality, model scale, and so on.

fileFormatVersion: 2
guid: 3f8a92b1c4d54e01a8b7f2e9d6c31a55
TextureImporter:
  ...compression, sRGB, sprite settings...

Why losing them breaks everything

If a .meta file is missing when Unity opens the project, Unity generates a new one with a new GUID. Every reference pointing at the old GUID now points at nothing: prefabs show "Missing" scripts, scenes lose materials, and UI references go blank. On a team, this is how one bad commit silently corrupts everyone's project.

The three golden rules

1. Always commit .meta files. Your gitignore must never contain a rule like *.meta. (Our template doesn't.)
2. Move and rename assets inside Unity, not in Explorer/Finder. Unity moves the .meta with the asset; your OS won't.
3. Commit assets and their .meta files together. A commit that adds a texture without its .meta (or vice versa) is a bug waiting for the next person who pulls.

Make them visible

Under Edit → Project Settings → Version Control, ensure Mode is set to Visible Meta Files. Hidden meta files can't be committed by Git at all, which guarantees breakage in any shared repo.

How to Put a Unity Project on GitHub (Step-by-Step for Beginners)

April 2026 · 8 min read · by the unity.gitignore team

Never used Git or GitHub before? This guide assumes zero prior knowledge and takes you from a Unity project sitting on your desktop to a safely backed-up repository on GitHub. Total time: about fifteen minutes.

What you'll need

• A free account at github.com
• Git installed (git-scm.com — accept the default options)
• Your Unity project

Step 1: Add a gitignore FIRST

This is the step beginners skip, and it's the most important one. Before touching any Git command, put a proper Unity .gitignore in your project's root folder — the folder containing Assets. Download ours here. Doing this first means the giant Library folder never enters your repository at all.

Step 2: Turn the folder into a repository

Open a terminal (on Windows: right-click in the project folder → "Open in Terminal" or use Git Bash) and run:

git init
git add .
git commit -m "Initial commit"

init creates the repository, add . stages your files (the gitignore automatically excludes the junk), and commit saves the first snapshot.

Step 3: Create the GitHub repository

1. On github.com, click the + icon → New repository.
2. Name it (e.g. my-first-game), choose Private unless you want the world to see it.
3. Important: do NOT tick "Add a README" or "Add .gitignore" — your local repo already has content, and initializing the remote creates a conflict.
4. Click Create repository.

Step 4: Connect and push

GitHub shows you the commands after creating the repo. They look like this:

git remote add origin https://github.com/YOUR-USERNAME/my-first-game.git
git branch -M main
git push -u origin main

The first push may ask you to sign in to GitHub through your browser. When it finishes, refresh the GitHub page — your project is live. Notice there's no Library or Temp folder: your gitignore did its job.

Step 5: The daily rhythm

From now on, saving your progress to GitHub is three commands:

git add .
git commit -m "Describe what you changed"
git push

Do this at the end of every work session. Each commit is a restore point you can return to — the closest thing game development has to a save file for the project itself.

Where to go next

Once you're comfortable, level up with Git LFS for large assets and, when you start working with others, our branching strategy for Unity teams.