TinaCMS怎麼用 Git無頭CMS編輯器教程

TinaCMS怎麼用：Git無頭CMS編輯器教程

TinaCMS是一個基於Git的無頭CMS，內容存在Git倉庫裡，編輯後自動提交，適合做靜態網站和文件站。它把內容模型、編輯介面和網站前端分開：訪客看到的是你的網站，編輯者則能在管理頁修改文章。下面以常見的JavaScript專案為例，帶你從安裝、配置到本地編輯和釋出走一遍。

先準備好Node.js、包管理器和一個已有的網站專案，比如Next.js或Astro。專案最好已經能在本機啟動，並把程式碼放進Git倉庫。還要確認文章檔案放在哪個目錄、使用Markdown還是MDX；後面的集合配置要和實際目錄、檔案格式對應。若專案尚未初始化Git，先提交一次初始版本，後續更容易檢查CMS改動。

第一步：安裝TinaCMS

在專案根目錄開啟終端，執行npx @tinacms/cli@latest init。初始化嚮導會詢問框架、內容位置等資訊，按專案實際情況選擇；若暫時不使用Tina Cloud，可以先跳過Cloud ID，先在本地試用。完成後檢查專案裡是否生成了.tina目錄，以及配置檔案和示例內容是否已出現。

接著檢視package.json裡的開發指令碼。常見配置是讓tinacms dev啟動CMS開發環境，同時執行原來的站點命令，例如Next.js專案可以將指令碼設為tinacms dev -c “next dev”。不要直接刪掉原有啟動引數；如果專案有自定義埠或環境變數，也一併保留。安裝完成後先執行一次，確認終端沒有依賴或配置報錯。

不同框架的接入細節會有差異，初始化提示也可能隨CLI版本調整。照著嚮導完成後，先別急著部署：進入專案中的.tina或tina目錄，確認配置入口在哪裡，再對照你實際的內容目錄。以Astro為例，通常透過CLI初始化並修改開發指令碼；Next.js則按專案生成的指令碼和路由配置執行。核心是讓CMS開發命令與網站開發命令一起工作。

第二步：配置集合和欄位

開啟生成的配置檔案，找到schema.collections。集合可以理解為一類內容的說明書，例如文章、頁面或作者；每個集合至少要設定name、label、path和fields。name建議用簡短且唯一的英文名稱，path寫倉庫內對應的內容目錄，label則是管理介面顯示給編輯者看的名稱，三者用途不同，不要混為一談。

比如文章存放在content/posts，就把path指向這個目錄；若文章是Markdown，可使用md格式，若專案用MDX則配置相應格式。fields中的每項對應一個可編輯欄位，常見有string文字、datetime日期和rich-text正文。欄位的name要與內容檔案裡的鍵名一致，label可以寫易懂的中文；正文通常標記為isBody，避免把文章主體誤當成普通標題欄位。

設定完欄位後，對照一篇真實文章檢查frontmatter鍵名、正文位置和副檔名。若欄位沒有出現在編輯頁面，常見原因是path寫錯、欄位name不匹配，或正文沒有正確指定。儲存配置後重啟CMS開發行程，讓生成的內容模型重新載入。先只配置標題、日期、摘要和正文，確認流程通了再逐步增加圖片、分類等欄位。

配置認證和權限

本地試用時，初始化配置可能啟用本地編輯模式；正式環境則應啟用適合部署方式的認證。使用Tina Cloud時，按專案配置填寫對應的客戶端資訊，並確保訪問內容API的請求經過授權校驗。不要把訪問令牌硬編碼進前端程式碼或提交到公開倉庫，應透過部署平臺的環境變數管理，並限制只有需要的環境能讀取。

權限方面，先明確誰能進入管理頁、誰能編輯或釋出。團隊專案可以使用服務提供的使用者和角色設定；自建認證則需要在CMS端實現登入狀態檢查、令牌獲取和退出邏輯，並在內容介面驗證令牌。不要只隱藏管理頁面入口就認為安全，因為介面仍可能被直接請求。配置完成後用未登入帳號測試，確認不能寫入倉庫。

第三步：啟動本地編輯和釋出

在終端執行專案的開發指令碼，然後開啟本地站點的管理路徑，常見入口是/admin；具體地址以框架初始化結果為準。首次進入時，選左側文章集合，再開啟一篇已有內容。修改標題或正文並儲存，然後回到專案目錄檢查對應Markdown檔案是否變化，確認CMS寫入的是預期檔案，而不是另一個目錄裡的副本。

本地儲存成功後，再預覽網站頁面，檢查標題、正文、圖片和日期是否正確顯示。若頁面沒更新，先確認網站讀取的內容路徑與集合path一致，再看構建工具是否需要重新生成頁面。建議小步測試：先改一篇測試文章，確認前端效果，再提交變更。CMS介面顯示成功並不一定代表網站模板已經正確讀取新欄位。

釋出時，將配置和內容變更納入Git提交，並在部署平臺連線對應倉庫與分支。若啟用生產環境線上編輯，需按所選方案設定內容API、認證資訊和回寫倉庫權限；完成後用測試帳號做一次編輯，檢查變更是否進入預期分支、構建是否成功。正式釋出前審查差異，避免把金鑰、臨時檔案或未經審核的內容一併提交。

日常使用中，編輯者在管理頁改內容，開發者負責維護欄位、模板和部署流程；新增欄位後要同步更新網站頁面的讀取邏輯。還要定期備份倉庫，並用Git歷史追蹤內容變更。若團隊更需要視覺化建站或AI輔助設計，也可以瞭解國內替代方案墨刀AI，訪問modao.cgref.cn。潤滅建議先從一篇測試內容開始，驗證編輯、預覽、提交和釋出整條鏈路，再開放給團隊成員使用。