Xcode 的 project.pbxproj 檔案採用文字格式儲存專案結構，但 Xcode 在新增檔案或修改設定時，不保證項目的插入順序一致。多人協作時，即使修改不同的檔案或 target，也可能因為項目順序差異而產生 merge conflict。這些衝突往往與實際變更無關，純粹是格式問題。

我的解決方案

將 project.pbxproj 中的各個區塊按固定規則排序，確保相同內容產生相同的檔案結構。配合 git pre-commit hook，每次提交前自動排序，團隊成員的專案檔就能維持一致的順序，大幅降低無意義的衝突。

我開發了一個腳本工具來執行這個任務，也已經在多個專案上跑了好幾年，GitHub repo 放在這裡：https://github.com/chiahsien/sort-Xcode-project-file

雖然目前推崇使用 Swift Package Manager 進行模組化，Xcode 16 也引入了 buildable folders 功能來減少專案檔變更，甚至也有 Tuist 或 Xcode Gen 這類的工具來生成專案檔，但這些新技術主要針對新專案或願意大幅重構的專案。對於已經開發多年、結構複雜的舊專案，貿然改用 SPM 模組化或轉換成 folder references 風險過高。此時，這個排序工具仍是最務實的選擇，能以最小成本解決 merge conflict 問題。

我們的 codebase 有用到放在 GitHub private repo 的 Swift package，為了讓 Xcode 能夠存取 private repo，必須讓 Xcode 認得 SSH key 才行。

因為 Xcode 只支援 RSA / DSA / ECDSA 這三種演算法的 SSH key，但 GitHub 不支援 RSA 跟 DSA 了，所以我們只剩下 ECDSA 可以用。

如果當時按照 GitHub 的文件建立 SSH key，它很有可能是 ED25519，這個演算法 Xcode 認不得，所以我們要新增一個新的 SSH key。

好幾年前我曾經寫過一篇讓 Xcode 專案易於版本控制的方法，它非常的好用，我也在多個專案裡頭使用這樣的配置用了好多年，都沒有出過什麼問題。

直到最近遇到了 SwiftUI 的 Preview 功能。

猜測可能是因為原先的設定是在 Build phase 去執行排序的 script，導致它破壞了 SwiftUI Preview 的一些機制，我想到了幾個解法，像是

• 不要放在 Build phase，放到 Run phase 去執行。
• 改用 XcodeGen 之類的工具產生 project file。
• 使用 git hook 的 pre-commit 來執行排序。
• 不要用，等真的遇到 merge conflict 了再說 lol

最後我選擇了 pre-commit 的做法。

情況

我有私人的 GitHub 帳號，為了方便自己跟公司管理起見，我用公司的信箱申請另一個 GitHub 帳號來存取公司的 repo。

問題

同一台電腦的一組 SSH Key 只能綁定到一個 GitHub 帳號，無法用同一組 SSH key 綁定到多組帳號，所以我無法把綁到私人帳號的 SSH Key 再綁到公司帳號。

解法

我要在同一台電腦建立不同的 SSH Key 對應到不同的 GitHub 帳號，並且在執行 git 操作時，系統會自動選擇對應的 SSH key。

Git-Flow 是 Vincent Driessen 在 2010 年提出的一套 Git 分支模型，簡單的說，它有 master 跟 develop 這兩個主要的分支，以及 feature / release / hotfix 這三個支援型分支，至於各個分支的用途看圖片應該就懂了，或是看原文有更詳細的說明。

由於當時大家對如何使用 Git 還處於摸索的階段，所以當這套規範被提出並且大家發現真的滿好用的之後，它很快就被廣泛的接受。

這個方法的步驟如下：

1. 建立一個 .gitattributes 檔
2. 輸入 *.pbxproj merge=union
3. commit 這個 .gitattributes 檔

這些動作告訴 Git 「針對 .pbxproj 檔要使用 union 的 merge 策略」，翻成白話就是「要包含對方的修改跟自己的修改」。

在之前的文章裡頭，我們已經將檔案照檔名排序了，所以當遇到合併衝突的時候，可以安心的包含對方的修改跟自己的修改。

參考來源