GitHub 對一般 Git 倉庫中的單一檔案設有 100 MiB 上限，超過便會拒收；官方大型檔案說明建議在這類情況考慮 Git LFS。
症狀：程式碼能 clone，但素材、模型或二進位檔沒有完整到位。
最快解法：在遠端 Mac 先確認追蹤規則與兩層認證，再按工作需要拉取 LFS 物件；完成磁碟檢查與真實專案復原演練後，才把環境當成可出發使用。
獨立開發者：你要在旅途中維護含模型、素材或二進位依賴的程式碼倉庫。
遠端設計與開發人員：你想用 iPad 或輕薄筆電連線到遠端 Mac 處理大型檔案。
技術自由工作者：你需要跨城市工作，並在換設備或租期結束時接手專案。
先判斷 Git LFS 遠端 Mac 配置是否對症
大型倉庫不一定就該導入 Git LFS。先分清楚你遇到的是檔案大小限制、倉庫歷史累積、頻繁下載，還是需要桌面軟體開啟素材；這些問題的處理方式不同。Git LFS 會讓 Git 儲存指向大型檔案的參照，檔案內容則由 LFS 服務管理，並不會自動備份整個工作環境。
什麼情況適合用 Git LFS？當模型、設計素材、音訊、影片或其他需要保留版本的二進位檔，確實要跟專案版本一起協作時，Git LFS 值得評估。若主要問題是建置產物佔空間，先考慮讓產物不進入版本控制；若需求是交付一份檔案給別人，檔案傳輸或雲端儲存可能更合適。
Git LFS 的適用檔案大小與儲存規則會受代管服務與方案限制，不能把一般 Git 的單檔限制直接當成所有 LFS 倉庫的上限。請先核對官方 LFS 檔案限制說明，並確認團隊的 LFS 儲存與傳輸額度。
第一步：先在測試分支建立可重複的環境
先確認遠端 Mac 上有 Git、Git LFS、專案倉庫存取權，以及足以容納工作目錄與下載物件的可用空間。安裝方式與支援條件應以Git LFS 官方安裝文件和目前的 macOS 環境為準，不要只因為 Git 指令可執行，就假設 LFS 元件已初始化。
在測試分支進行設定，避免直接改動正式分支的追蹤規則。以下範例適用於已安裝並初始化 Git LFS、且你確定要版本管理 PSD 素材的專案：
git lfs install
git lfs track "*.psd"
git add .gitattributes
git commit -m "Track design files with Git LFS"
git lfs track 會更新 .gitattributes，因此追蹤規則要跟著程式碼提交，讓其他工作者也能套用；檔案類型與規則寫法可核對官方追蹤文件。若團隊已有規則，先檢查是否重複或互相覆蓋，再新增模式。
| 配置方式 | 適合情境 | 優點 | 代價與評分 |
|---|---|---|---|
| 完整拉取目前工作所需 LFS 物件 | 需要完整開啟目前分支專案 | 工作樹內容較完整 | 初次傳輸與磁碟需求較高；完整度高 |
| 依路徑或檔案類別選擇性拉取 | 只處理部分素材或子目錄 | 減少非必要下載 | 需確認任務檔案範圍；容量效率高 |
| 只 clone 程式碼、稍後再抓 LFS 物件 | 先檢查程式碼，素材稍後才用 | 可把下載安排在網路較穩定時 | 容易誤以為專案已完整；上手便利、完整度低 |
第二步：分開驗證程式碼、LFS 與遠端登入憑據
一次 git clone 成功，只能說明程式碼倉庫連線正常，不能證明 LFS 物件也已授權、下載並可用。你至少要分開檢查三件事：Git 倉庫的認證、LFS 服務端點的認證，以及登入遠端 Mac 所用的 SSH、VNC 或控制台憑據。它們可能走不同的驗證流程。
Git LFS 會透過服務探索與認證流程連線到 LFS 端點，可參閱服務探索文件及認證機制說明。實作時使用團隊核准的憑據管理方式，避免把存取權杖直接寫進遠端 URL、腳本或提交內容。若反覆跳出登入視窗，先確認使用者帳戶、憑據助手與 LFS 端點授權，再重試拉取。
Git LFS 憑據怎麼設，才能減少反覆登入？先依你的代管服務確認認證方式，再檢查 Git 憑據助手是否已儲存正確帳戶；不要用 SSH 登入遠端 Mac 成功，推斷 LFS 服務也必然授權。更換密碼或權杖後，更新對應憑據，並用實際下載驗證，而不是只看 clone 結束時沒有報錯。
第三步：按任務選擇拉取範圍
完整拉取適合要開啟整個專案、執行整合測試，或無法預先確定所需素材的工作。若你只需處理指定類別，可以依官方文件使用 git lfs fetch 的 include 或 exclude 規則，再按需要將物件檢出到工作目錄；可用選項與行為應以fetch 文件為準。
| 你要完成的工作 | 拉取策略 | 驗收方式 | 主要風險 |
|---|---|---|---|
| 開啟目前分支全部素材 | 拉取目前工作所需的 LFS 物件 | 確認素材能在實際應用程式開啟 | 初始下載量可能較大 |
| 只修改指定素材類別 | 以 include／exclude 限定物件範圍 | 抽查任務內每種檔案 | 規則漏掉依賴檔案 |
| 先檢視程式碼再安排下載 | 先 clone，待網路穩定後抓取 LFS 物件 | 確認指標檔已替換為可開啟的內容 | 把尚未下載的指標誤當完成檔案 |
Git LFS 能否在遠端 Mac 使用？可以，只要該 Mac 的系統環境支援你採用的 Git LFS 安裝方式，而且倉庫與 LFS 端點都有可用憑據。網頁控制台或 SSH 能連上主機，不代表圖形應用、檔案空間與 LFS 下載已準備完成；第一次設定應在測試分支用真實專案驗證。
第四步：用弱網流程驗證失敗復原
旅途中不要把一次下載成功當成唯一驗收方式。酒店、咖啡館與機場的網路品質可能改變，你應安排在相對穩定的連線下開始大檔拉取，記錄出錯的檔案與訊息；連線恢復後，依錯誤原因重新執行拉取，再確認檔案內容，而不是只看命令結束狀態。
遠端 Mac 拉取 Git LFS 檔案失敗時怎麼處理？先分辨是 Git 倉庫認證、LFS 端點授權、頻寬中斷，還是伺服器端物件不存在；保留錯誤訊息，再只重試未完成的下載。重新連線後，用應用程式實際開啟檔案，並執行 git lfs fsck 檢查本機 LFS 物件狀態；檢查範圍與用途可參考官方 fsck 文件。
螢幕上看到的檔案名稱可能只是 LFS 指標。若應用程式無法開啟，先確認物件是否真的下載並還原，再判斷素材本身有沒有損壞。
第五步：監控磁碟，而不是預設固定容量
遠端 Mac 的空間可能同時被工作目錄、LFS 物件快取、匯出檔、暫存素材與應用程式占用。要判斷是否安全，請在拉取前後記錄可用空間，並按資料夾檢查變化；不同專案、分支與檔案版本造成的占用差異很大，不能用一個通用容量數字代替現場測量。
清理前先確認檔案已提交、需要保留的輸出已另行保存，且未提交的變更已備份。git lfs prune 用來清理符合條件的本機舊物件，不等於刪除遠端 LFS 檔案；執行前查看官方 prune 文件，並確認哪些物件仍需要供離線或回退工作使用。
旅行中如何管理遠端 Mac 的大型程式碼倉庫？把工作切成可驗證的批次：先拉程式碼，再抓當前任務必要的 LFS 物件，完成一項素材工作後保存提交與匯出檔，最後檢查工作目錄與快取。若剩餘空間不足以容納下一批檔案和必要輸出，先停止下載，清點可刪項目或調整工作範圍，不要在未確認資料可恢復前執行清理。
用條件分支決定拉取與遷移策略
- 若當前任務需要整個分支的模型與素材，就完整拉取該工作所需物件；否則按路徑或檔案類型縮小範圍。
- 若 LFS 端點尚未通過獨立認證，就先修正憑據；否則再進行大檔下載。
- 若網路容易中斷，就分批下載並記錄失敗檔案；若網路穩定且專案需完整驗收，再擴大拉取範圍。
- 若租期結束後仍要在另一台 Mac 接手，就先確認程式碼、LFS 物件、未提交改動、環境變數與必要輸出各自如何交接；否則不要只留下一份工作目錄。
- 若專案需要保留歷史版本，就保留倉庫及其 LFS 物件的可存取路徑；否則也要明確保存交付所需檔案，不能把 Git LFS 當成備份方案。
租期結束時，逐項驗證專案可接手
Git LFS 專案結束後如何遷移與清理？先決定要延續同一台遠端 Mac、搬到另一台 Mac，還是交給臨時設備接手。接著列出程式碼提交、LFS 追蹤規則、必要物件、未提交變更、環境變數與專案輸出；只在新環境完成認證、拉取並能打開真實檔案後，才清理舊工作目錄。
若要搬到另一台 Mac，先確認新環境連得上原倉庫與 LFS 端點，並實際拉取專案所需物件。若要交接給其他工作者，除了程式碼網址，也要說明 LFS 權限、追蹤規則及尚未提交的工作。遠端 Mac 的服務與使用方式可先從SSHMac 服務頁面確認；遇到帳戶或連線疑問，可查閱說明中心。
自己帶 Mac 出行的方案不必額外依賴網路連線，卻需要攜帶並保護實體設備，還要自行確保本機備份與環境復原；在旅途中遺失或損壞設備，也可能讓工作中斷。遠端 Mac 則以穩定網路為前提，仍不適合必須離線工作、依賴本機實體介面的任務。若你已用真實專案完成 Git LFS 拉取與復原演練，且希望減少隨身設備負擔，可評估透過 SSHMac 租用遠端 Mac，接著再核對儲存、備份與檔案傳輸能力，確認大型專案能在整個工作週期內交接與恢復。