--- title: How do I add a file type to Git LFS tracking? description: To add a file type to Git LFS tracking, you must add an entry in the .gitattributes file in your repository --- [Skip to content](https://help.copia.io/knowledge/how-do-i-add-a-file-type-to-git-lfs-tracking#main-content) English Show submenu for translations [More support](https://help.copia.io/knowledge/kb-tickets/new?hsLang=en) ![](https://help.copia.io/hubfs/Logo_Hotdog_BlackWhite%20(1).svg) Open main navigation Close main navigation - English Show submenu for translations - [More support](https://help.copia.io/knowledge/kb-tickets/new) - Contact us Contact us How can we help you? - There are no suggestions because the search field is empty. 1. [Copia Help Center](https://help.copia.io/knowledge?hsLang=en) 2. [Source Control FAQ](https://help.copia.io/knowledge/source-control-faq?hsLang=en) 3. [Git Questions](https://help.copia.io/knowledge/source-control-faq?hsLang=en#git-questions) # How do I add a file type to Git LFS tracking? ## To add a file type to Git LFS tracking, you must add an entry in the .gitattributes file in your repository   #### **What is Git LFS?** [Git LFS](https://git-lfs.com/) *(Large File Storage*) keeps big files — PLC projects, images, videos, binaries — out of the normal Git history. In your repo, they're replaced by tiny pointer files, and the real content lives on the LFS server. **Result**: faster clones, smaller history, same versioning. You can find more information about Git LFS in [our Documentation](https://docs.copia.io/docs/git-based-source-control/basic/making-changes/binary-and-large-files#git-lfs).  --- #### **The .gitattributes pattern** Your .gitattributes file uses this style: `### *.zip` `*.[zZ][iI][pP] filter=lfs binary` The ### line is a comment header. The bracketed letters (\[zZ\], \[iI\], \[pP\]) make the match case-insensitive, so file.zip, FILE.ZIP, and File.Zip are all caught. Copy this pattern for any new extension (examples): | **Extension** | **Add this** | | --- | --- | | .psd | `### *.psd` `*.[pP][sS][dD] filter=lfs binary` | | .bin | `### *.bin` `*.[bB][iI][nN] filter=lfs binary` |   --- #### **Getting Started** You have three options. Pick based on your goal: | #### **Option** | #### **What it does** | #### **Shrinks repo size?** | #### **Risk** | | --- | --- | --- | --- | | **A. Track going forward** | Future commits go to LFS; old files stay as-is | ❌ No | None | | **B. Rewrite all history** | Moves every old version into LFS, in place | ✅ Yes | High | | **C. Archive old repo, start fresh** | New clean repo with LFS; old repo preserved read-only | ✅ Yes | Medium | ### **Option A — Track going forward (safest)** **Best for:** Adding to LFS prior to repo size being an issue 1. Switch to the shared branch (e.g. main), pull latest. 2. Add the new entry to .gitattributes. 3. Commit and push. Message: Track \*.psd files with Git LFS. 4. Let everyone else know to Pull a fresh copy of the repo Done. New .psd files go to LFS; older versions stay where they are. ### **Option B — Rewrite all history (coordinated)** **Best for:** When you genuinely need to reduce repo size on disk. ⚠️**WARNING** - This could break branch and PR references in history, **Option C** is recommended, as a safer option. **Before you start:** - 📦 Back up the repo: `git clone --mirror backup.git` - 📅 Schedule a maintenance window - 📢 All collaborators must push their work and stop pushing during the migration - 🔓 Be ready to temporarily disable branch protection rules **Steps:** 1. Make a fresh clone in a separate folder (don't use your daily workspace): 1. `git clone repo-lfs-migrationcd repo-lfs-migrationgit fetch --all` 2. Add the new entry to .gitattributes on the default branch, commit. 3. *(Optional)* Preview impact: 1. `git lfs migrate info --include="*.psd" --everything` 4. Run the migration across all branches and tags: 1. `git lfs migrate import --include="*.psd" --everything` 5. Review .gitattributes and remove any duplicate line. 6. Force-push everything: 1. `git push --force-with-lease --allgit push --force-with-lease --tags` 7. Tell everyone to **re-clone the repo**. Old clones will be very hard to reconcile. ⚠️ Open PRs and code reviews referencing old commit hashes may break. Give reviewers a heads-up. ### **Option C — Archive old repo, start fresh (cleanest break)** **Best for:** When you don't need full Git history in the active repo and want to avoid force-pushes. | **✅ Use Option C if...** | **❌ Skip Option C if...** | | --- | --- | | Old PRs and commit links should stay readable, not break | Lots of tooling/scripts assume the current repo URL | | You don't lean on git blame or old history day-to-day | Day-to-day work depends on full Git history | | You want to avoid touching branch protection or force-pushing | | **Before you start:** - Ask the team to merge or close any open PRs they care about - List everything pointing at the current repo URL: CI/CD, deployments, docs, dependent repos, dashboards, bookmarks. You'll update all of them. **Steps:** 1. On your Git host, create the new (empty) repo. Use a suffix like -v2 or -lfs, or a fresh name. 2. Clone the old repo into a clean folder, then drop its history: 1. `git clone new-repocd new-reporm -rf .git` 3. Initialize fresh: 1. `git initgit lfs install` 4. Confirm .gitattributes came over correctly. Add any new entries. 5. Stage, commit, push: 1. `git add .git commit -m "Initial commit (migrated from )"git remote add origin git push -u origin main` 6. Match the new repo's settings to the old one: branch protection, reviewers, webhooks, deploy keys, secrets, integrations. 7. **Archive the old repo.** Most Git hosts offer this as a one-click setting — it makes the old repo read-only. Old PRs, issues, and commit links remain accessible. 8. Update everything pointing at the old URL. 9. Tell everyone to clone the new repo. ⚠️ Open PRs don't carry over to the new repo. Recreate any in-progress work as branches in the new repo before archiving. Some Git hosts can transfer issues — check before archiving if you want them moved. --- #### **Verifying it worked** - **Web App:** look for an "LFS" badge next to the file in the repo - **Local command, list everything in LFS:** - `git lfs ls-files` - **Open .gitattributes locally** and confirm your entry is there in the right style. --- #### **Troubleshooting** | **Problem** | **Fix** | | --- | --- | | Push rejected on a protected branch | Temporarily disable branch protection, push, re-enable. | | LFS asking for credentials or rejecting uploads | Run git lfs env to check the endpoint. Some hosts need a personal access token, not a password. | | Teammates' branches broke after a history rewrite | Expected after Option B. They re-clone, or save work aside and re-apply. (Consider Option C next time.) | | Repo size didn't shrink on the server | Most hosts don't reclaim storage until garbage collection runs (hours/days). Some need a support request. | --- #### **Command reference** Used in Scenario 2 and Scenario 3 Options B and C. Everything else is desktop-client only. | **Command** | **What it does** | | --- | --- | | `git lfs ls-files` | Lists files currently in LFS | | `git lfs migrate info --include=""` | Previews how much space an extension uses (no changes) | | `git lfs migrate import --include="" --include-ref=` | Moves existing files on a specific branch into LFS | | `git lfs migrate import --include="" --everything` | Moves existing files across all branches and tags into LFS | | `git push --force-with-lease` | Safely force-pushes a rewritten branch | | `git lfs env` | Shows your LFS configuration |   - [Getting Started](https://help.copia.io/knowledge/getting-started?hsLang=en#main-content) - [Sales Wiki](https://help.copia.io/knowledge/getting-started?hsLang=en#sales-wiki) - [Account Management](https://help.copia.io/knowledge/getting-started?hsLang=en#account-management) - [Customer Experience](https://help.copia.io/knowledge/getting-started?hsLang=en#customer-experience) - [Source Control FAQ](https://help.copia.io/knowledge/source-control-faq?hsLang=en#main-content) - [Web App](https://help.copia.io/knowledge/source-control-faq?hsLang=en#web-app) - [Git Questions](https://help.copia.io/knowledge/source-control-faq?hsLang=en#git-questions) - [Desktop App](https://help.copia.io/knowledge/source-control-faq?hsLang=en#desktop-app) - [Tutorials](https://help.copia.io/knowledge/source-control-faq?hsLang=en#tutorials) - [Best Practices](https://help.copia.io/knowledge/source-control-faq?hsLang=en#best-practices) - [Source Control](https://help.copia.io/knowledge/source-control-faq?hsLang=en#source-control) - [DeviceLink FAQ](https://help.copia.io/knowledge/devicelink-faq?hsLang=en#main-content) - [Siemens TIA Portal](https://help.copia.io/knowledge/devicelink-faq?hsLang=en#siemens-tia-portal) - [Agent](https://help.copia.io/knowledge/devicelink-faq?hsLang=en#agent) - [General](https://help.copia.io/knowledge/devicelink-faq?hsLang=en#general) - [Rockwell Studio 5000](https://help.copia.io/knowledge/devicelink-faq?hsLang=en#rockwell-studio-5000) [![Chill listening crop-3](https://help.copia.io/hs-fs/hubfs/Logo_Hotdog_BlackTeal-1.png?width=87&height=24&name=Logo_Hotdog_BlackTeal-1.png "Chill listening crop-3")](http://copia.io) 43 W 24th St, 6th Floor New York, NY 10010 [mailto:email@email.com](mailto:email@email.com) Copyright © 2025, Copia Automation, Inc.