把 AI 開發記憶放進 Git：Claude Code 團隊記憶共享與版本控制思路

AI Coding × Git Memory × Team Workflow

AI 開發記憶不該只存在單一對話：用 Git 把它版本控制起來

這則 Threads 的核心觀點是：AI 輔助開發產出的專案經驗、決策與風格，不應卡在單一會話或單一成員的 AI 裡。若能像程式碼一樣用 Git 版本控制，團隊就能共享最新脈絡，降低每個 AI 都像新同事從零開始的問題。

查核補充：文中提到的 ingram-technologies/claude-git-sessions 可在 GitHub 查到，描述為透過 orphan git branch 在團隊間共享 Claude Code sessions。文中另一個 hippoagent 連結在本次查核時未能以原文路徑確認，應視為待驗證線索。

為什麼 Git 適合管理 AI 記憶

可回溯

團隊能知道某條專案記憶、部署規則或架構決策是何時加入、由誰加入、為什麼改。

可共享

不再是每位工程師各自的 AI 記憶，而是專案級共同資產。

可分支

不同實驗、feature branch 或 agent session 可保留各自上下文，又不污染主線。

傳統做法	Git-based AI memory	價值
CLAUDE.md 靜態規範	會話與決策可更新、同步、回溯	從靜態文件走向動態專案記憶。
每個人的 AI 各自記得	團隊共享同一套專案經驗	風格與脈絡更一致。
任務結束後經驗消失	經驗寫入 repo 或 orphan branch	踩坑與決策可累積。

落地時的風險

不要把祕密寫進記憶：API key、token、客戶資料、私密對話不能進 Git。
需要 review：AI 自動寫入的記憶可能錯、過期或過度泛化，應走 PR / review。
要區分層級：個人偏好、團隊規範、專案決策、短期任務狀態不能混在一起。
要處理衝突：多人 agent 同時寫 memory 時，merge conflict 與語意衝突都要有流程。

對 BigIntTech / Hermes 的啟發

這篇和 Hermes 的 skills / memory / session_search 很相近，但 Git-based memory 更適合「專案內可審核的共同規則」。硬規則仍應放 CLAUDE.md / AGENTS.md；可重用工作流放 skill；專案團隊共享經驗可考慮進 repo，以 PR 管控品質。

Source: Threads / @crazyaitools_