原文是 John Porter 寫的《A Symphony Workflow》，參考了許多網路上的文章以及 O'Reilly's Version Control with git 一書的內容。
目的是建置一個 Symphony CMS 的開發與部屬環境，規範自己的工作方式，同時作為未來每一專案的開發基礎。
ps.Symphony CMS 確實只是個 PHP 的程式，而 PHP 的部署又遠比其他程序簡單，但 Symphony CMS 之所以部署起來複雜的原因，是因為使用了 git submodules 管理所有的外掛，外掛的安裝有可能會修改資料庫結構。Symphony CMS 的升級流程遠比想像中複雜難搞，這可能是未來的 Symphony CMS 必須審慎思考並重新架構的環節。
後面的文章都假設你打算部署 Symphony 的開發專案，也都將它們儲存在私密的遠端倉儲之中（使用 bitbucket 或付費版的 GitHub，當然也包含自己在主機上建立的 bare git）。倘若你使用公開倉儲進行後面的程序，許多與網站相關的隱私資料（例如資料庫密碼）都可能會對外公開，後果必須自行負責，撰文者不負任何責任。你已經得到警告了歐！
基本的準備工作：清楚列出必要的步驟。
預先設置 Master、Develop 與 Symphony 三個常時存在的分支，這是讓開發作業清楚簡單的關鍵，讓主線開發（mainline development）、臭蟲修改（bug-fixing）與緊急的補丁（quick-fix, hotfix）並時存在，才能真正善用 git stash 與臨時分支的威力。
參考 A successful git branching model, by Vincent Driessen 一文，實際上就是 git flow 的概念闡釋，但不會使用 git flow 這個 git 附加程式。
我們會從 master、develop 與 symphony 三個分支開始。
等一下！ symphony 不在上面提到的分支模型之中吧？
對，確實。使用 Symphony 架設網站時，核心程序常常也會三不五時更新，因此我們需要一個常時的獨立分支，用來升級核心程式，在獨立的分支之中處理核心升級時的版本衝突、測試整合，不影響正常的開發工作。
使用 BitBucket 私密倉儲（免費），或是付費使用 GitHub 私密倉儲（最便宜的月費可以擁有五個私密倉儲）。一開始只需要個人的私密倉儲，以及 Symphony 的核心倉儲兩個遠端資訊就可以了。
如果想要部署網站到具備 git 能力的伺服主機，就有可能多出其他一、兩個遠端（例如 product 是正式環境、stage 是測試環境等等）。這篇文章尚未涵蓋這些流程。
使用 Illustrator、Inkscape 或任何 UML/ERD 軟體，畫出具體流程的圖像，有助釐清流程、幫助記憶。
始終覺得 Submodules 是很難管理的東西，但因為 Symphony CMS 的外掛幾乎都是採用 Submodules 維護，還是必須搞懂它。升級或是移除 Submodules 不時會碰到問題（尤其是移除），Git Submodules 在 Git 的生命歷程中算是比較新的玩意，所以事前的規劃更為重要，遵循一套標準流程可以減少日後的麻煩。
- 將所有會用到、使用中的外掛，記錄一張列表，當然是必要的。（手動維護）
- 目前 Symphony CMS 已經有了一個單獨的外掛網站，可以使用 GitHub 帳戶登錄，未來如果能有一個功能，讓用戶勾選並維護一份外掛清單，建立一個專用倉儲，安裝 Symphony CMS 時選擇以 submodule 模式加入，流程上應該會更順暢。
- 現在就維持一份獨立的外掛倉儲，擺放所有會用到的 extensions。
清單當然要包含名稱、倉儲的連接位置，以及個人的註記（使用經驗）。
（Symphony CMS 的外掛（extension），使用了 git submodule，對於熟悉 git 的開發者來說，或許是項福音，但這項功能實際上一般 git 使用者也不一定常常用到，需要花些時間練習。）
至於 Symphony CMS 的外掛，最好是建立一份下面這樣的清單，就能夠使用自動化的方式一次安裝。這份清單必須是一份純文字檔的 csv，就像這樣：
git://github.com/symphonycms/export_ensemble.git,extensions/export_ensemble
git://github.com/symphonycms/markdown.git,extensions/markdown
git://github.com/symphonycms/maintenance_mode.git,extensions/maintenance_mode
git://github.com/symphonycms/selectbox_link_field.git,extensions/selectbox_link_field
git://github.com/symphonycms/jit_image_manipulation.git,extensions/jit_image_manipulation
git://github.com/symphonycms/profiledevkit.git,extensions/profiledevkit
git://github.com/symphonycms/debugdevkit.git,extensions/debugdevkit
git://github.com/symphonycms/xssfilter.git,extensions/xssfilter
注意在網址與安裝目錄之間，只用一個半形逗號區隔，沒有任何空白鍵，必須要這樣設置，才能夠自動化的正常匯入。
上方列表中都是 Symphony 預設的外掛，因此你不需要重複填寫他們，只要將你需要額外安裝的外掛，以同樣的方式書寫即可。
第一部分是外掛的 git 倉儲網址，請使用唯讀的連結形式，不要用那種會將修改送回 github 的開發連結，非必要的修改、提交問題，可能會造成原開發者的困擾。第二部分則是你的安裝目錄，相對於根目錄而言。如果你依照上面的範例正確製作了這份清單， 接下來 的自動化程序會讓你輕鬆不少。
你可能會使用不少外部的資源，例如 jQuery, jQuery plug-ins 等等，制作一份清單或許對未來有些幫助，不過不用太擔心，隨著開發過程的進展，你會更清楚該如何配置它們。
ps.目前已經有很多協助建置、自動化、處理套件相依性的新方法，例如 Yeoman 就整合了 yo、grunt 與 bower 三大工具。這些新工具通常都是運作在 Node.js 環境，根本來說也是為了 webapps 設計的。
現在準備得差不多了，可以開始幹活了...
我們用 mywebsite 作專案範例，你可以自由使用任何名稱。
我們不會使用 git clones 開始，複製一個遠端倉儲回來對很多專案來說，都是很方便的程序，但這份工作流程是使用一份既存的、修改過配置的程式作為起點，並不是單純的複製，因此我們需要一點額外的調整。
首先，我們需要設置專案。我個人的習慣是替每個專案建立一個根目錄，像是這樣：
/mywebsite // 將開發工具的起點設置在此
/mywebsite/httpdocs // 要擺在網站伺服器下的檔案，是一個 git 倉儲
/mywebsite/project-files // 擺放所有與專案相關的額外文件
這種配置，可以讓開發工具與文件擺放在 git 倉儲之外，讓程式的工作區域乾淨些。
使用終端機界面，建立這些目錄，並起始 git 倉儲：
mkdir mywebsite mywebsite/httpdocs mywebsite/project-files
cd mywebsite
git init
接著我們可以開始設置遠端倉儲對應了。
我們至少要替專案設置兩個遠端倉儲，一個是 Symphony 程式的 github 倉儲，另一個則是自己專案的遠端倉儲。
對 Symphony 而言，我們會使用一些額外的 git 功能，限制從遠端拉回來的資料。這樣做的好處是，不會讓 Symphony 倉儲中那些我們不會用到的資訊，例如 Symphony 的版本標籤與其他分支，混淆我們的專案。
我們會這樣設置：
-
--no-tags確保不會拉回 Symphony 的所有標籤。這樣做的好處是，你不用擔心：萬一我替自己的專案網站打上 2.0 或 2.1 的標籤，卻又與 Symphony 原來的標籤衝突時，該怎麼辦？
-
-t master確保只使用 master 分支（你可能會注意到，現在好像同時追蹤了兩個分支，但我們晚點會修改它。）
在終端機界面中，添加下面兩個遠端倉儲
git remote add --no-tags -t master symphonycms git://github.com/symphonycms/symphony-2.git
git remote add mywebsite git@github.com:myusername/mywebsite.git
第二個遠端倉儲，使用了 ssh 的 git 協定，才能夠讓我們擁有可以寫入的權限， myusername 是你在 github 上的用戶名稱，必須依照每個人的不同對應修改。
在建立常時分支之前，我們需要讓專案有一些既存的內容，因此 fetch 與 pull Symphony 官方倉儲中的內容到我們的專案目錄裡。
首先我們先 fetch （取回）Symphony 遠端倉儲中的參考資料，在這一步驟，我們要確保不要複製所有 Symphony 的歷史開發資料，讓我們的專案過於膨脹。
在終端機界面中，取回 Symphony 倉儲資料
git fetch --depth 1 symphonycms
接著我們拉進 pull Symphony 倉儲，讓後續建立分支時都有一個內容的起始點，也才能設置與私有遠端倉儲之間的追蹤關係。如果你嘗試從空的倉儲建立追蹤，會發生問題而無法設置成功。
使用終端機，拉進 Symphony CMS 的資料
git pull symphonycms
如此一來，我們就可以開始建立分支了。我們應該遵循「最佳實踐」原則，清楚指明分支的起始點。雖然不是必要程序，但養成良好習慣是件好事。我們目前與預設的起始點，是 master 主分支。
使用終端機，建立需要的分支
git branch symphony master
git branch develop master
現在我們建立好三個需要的分支了。
遠端追蹤（Remote tracking）能讓日常工作簡單些，當使用 push 或 pull 指令時，不用花時間查看目前處在哪個分支、找出正確的遠端分支對應名稱。當開發工作持續進展，有一堆不同的 features/bug-fixes/developers 分支時，在這些分之間頻繁切換與管理，會讓你十分混淆。在一開始就花點時間替分支設置好正確的遠端追蹤，有助於未來的開發工作。
接著，我們需要把本地的內容推上專案的遠端倉儲，才能夠有東西可以追蹤，所有分支都需要（包含 Symphony 分支）。如果你省略了這個步驟，當設置遠端追蹤時，git 會回報錯誤。因此我們需要：
使用終端機，推送我們的所有倉儲
git push --all mywebsite
現在可以設置各分支的追蹤關聯了。
在終端機中，輸入下列指令
git branch --set-upstream master mywebsite/master
git branch --set-upstream develop mywebsite/develop
git branch --set-upstream symphony symphonycms/master
基本上就是設置 upstream，建立本地分支與遠端倉儲分支的追蹤關聯，也能讓 git 在我們提交變更時，提供一些有用的資訊，例如本地分支目前領先遠端多少個提交，或是遠端分支比本地分支有更多的提交。這些簡單的資訊，對多人協同開發的工作來說，會非常關鍵。
當然最方便的，還是可以在提交時省略指定分支的輸入，不管我們目前在哪個分支，只要輸入：
git push mywebsite
而不用指定（遠端倉儲對應的分支名稱）
git push mywebsite master
或是
git push mywebsite develop
到這裡，基礎的設置完成。接下來請切換到開發分支（develop），進行後續的工作。
從終端機界面，切換到 develop 分支
git checkout develop
加入外掛模組非常簡單，但要謹慎做對，因為移除 Symphony 的外掛模組不是件小工程，請務必閱讀 Removing Submodules 的內容。
加入外掛模組，需要知道外掛的倉儲路徑，以及外掛安裝目錄的名稱。由於外掛開發者並沒有遵循一致的目錄命名原則（因為根本沒有？），所以通常必需手動指定。
如果你有遵照前面的指示建立外掛文件 Planning A Symphony Workflow ，現在就只要拷貝貼上。
在終端機界面中（從本地倉儲的根目錄），輸入：
git submodule add git://github.com/developer/extension.git extensions/extension
其中的 git:// 路徑是外掛的倉儲，接著則是我們希望在本地的 /extensions 目錄下建立的外掛目錄名稱，這些第一次都必須輸入正確，一旦外掛建立了，就無法修改與變更內容了（這正是使用 git submodules 管理外掛的麻煩之處）。
（下面是原文作者使用終端機指令，批次安裝外掛的方式。由於很難在專案初始時就百分百確認要用哪些外掛，因此這流程不太有用。
Update: 2013/12/14
以一個自動化列表（csv）管理 Symphony CMS Extensions 的流程，已經被整合進 Symphonyno5.sh 指令之中。除了新建專案非常快速便利之外，更新與新增外掛更是順暢。
- 在根目錄下維護一份
extensions.csv檔案，每一列填入外掛的 Git 位置，以半行逗號區隔，後面則是extensions/外掛目錄，基本上完全依照 Symphony Extensions 網站上的指令複製修改即可。 - 執行
symphonyno5 extensions，會更新外掛；若是列表中有新增外掛也會自動添加。
注意事項：
- 我將 symphonyno5 指令檔中更新 submodule 的指令部分修改成了
git submodule update --init --recursive，是因為有些外掛還有次一層的 submodule，原有指令會漏掉添加外掛中依賴的外部程序，造成安裝不完全。 - 有些特殊的外掛，若是在新建專案時一股腦加入會有問題，多半是因為依賴其他外掛建立後的資料庫，目前發覺與多語相關的一系列，還有電郵版型與電子報管理的外掛都會有問題，因此修改了 symphonyno5 倉儲下的 extensions.csv 檔案，讓它只包含最基本的一些外掛，在網站建立完成、建立會員資料表之後，再修改列表，執行
symphonyno5 extensions更新與添加就不會發生問題了。
The first thing you will need is the list of extensions you should have made during the Planning A Symphony Workflow section. We will need this to automate the extension adding. Thoroughly check this list to make sure that there are no mistakes, as the automation process isn't foolproof by any means, and will just keep on trucking past mistakes.
In a text editor of your choice, write this code out
#!/bin/bash
filename="$1"
while IFS="," read one two
do
git submodule add "$one" "$two"
done < "$filename"
git submodule update --init
What's that? Doesn't make any sense to you? No, me neither, but it works. Thanks go to ghostdog74 on stackoverflow.com for writing this for me. I'm no bash-er and would never have come up with this.
Once you have this script, save it as git-auto-submod.sh, somewhere that you can access it via your shell.
On my Mac, I have it saved under /usr/local/bin which is in my path. You will need to give it Execute permissions to use it too.
OK. Ready? Grab the path to the list you made earlier.
In Terminal, from the root of your repo, run the script
git-auto-submod.sh path/to/extensions.csv
This will automatically add every extension you have listed in the csv file. Magical eh?
Git 的 Submodules 平時用起來相當酷，但一旦你想要移除，就立即成為一場夢魘。
搞不清楚為什麼沒有一道魔術指令可以輕鬆使用，在那道指令被發明出來之前，可以參考先烈們的手法，例如 移除外掛的步驟 。
Update 2013/12/14
這一部分的複雜流程，symphonyno5.sh 也已經解決，使用 symphonyno5 new project-name 建立專案之後，程序會移除原始倉儲、建立新倉儲、建立 master 與 develop 兩個分支，就連不同的配置檔也一併處理完成。
替一個 Symphony 開發專案建立多個伺服器配置檔（用於不同主機，例如本地開發、測試環境、正式環境），這功能有被討論過，但在被加入核心程序之前，我們先遵從 Rowan Lewis 建立多個配置檔的手法。
警告： 這裡就是前面免責聲明的關鍵， manifest/config.php 裡有連接資料庫的細節資訊，使用這裡的方法將會讓這些資料被 Git 紀錄下來。因此若是你用公開的遠端倉儲，任何人都能存取你的資料庫！
下面的流程取材自 Rowan's article。
Rowan 使用了兩個配置目錄，但我習慣使用三個 (開發 dev，測試 staging，正式主機 production）。
首先，因為我們還沒有安裝 Symphony，因此需要手動建立這些配置目錄。
開啓終端機、從本地倉儲的根目錄，建立下列目錄：
mkdir manifest manifest/cache manifest/logs manifest/tmp
接著需要增加一些 git ignore 清單，確保某些資料不會被 Git 追蹤。
開啓終端機，建立下面的忽略清單檔案
touch manifest/cache/.gitignore manifest/logs/.gitignore manifest/tmp/.gitignore
這些檔案終都需要加入下面的內容：
*
!.gitignore
這樣就讓 Git 知道，除了 .gitignore 檔案自身之外，其他檔案都不必追蹤修訂，也就是讓 Git 忽略暫存檔、系統記錄等。
現在，我們要用這個配置目錄來建立 live 與 development 配置檔。
既然我們正在建立一個三重主機開發流程，就需要替流程中每一台主機，複製一次這個配置目錄。
開啓終端機、複製配置目錄，在最後加上辨識資訊
cp -R manifest manifest.dev
cp -R manifest manifest.stage
mv manifest manifest.prod
最後一條指令將 manifest 目錄改名成正式主機的配置目錄，這樣比複製三次、再刪除原先的，簡單一點點。
如果現在安裝 Symphony，它會忽略掉前面我們的辛苦工作，又建立一個全新的 manifest 目錄，因此我們要通知一下 Symphony。建立一個「鏈結」、指向對應的配置目錄。
開啓終端機，建立 symbolic link
ln -s manifest.dev manifest
接下來我們需要將三個配置目錄都讓 Git 追蹤。
等一下，只有三個？我們剛剛建立的那個鏈結怎麼辦？
好問題。我們並不讓 Git 追蹤 manifest 目錄下的內容，因為裡面有一大堆臨時產生的檔案、暫存檔，這是 Symphony 預設的規劃；況且每一個目錄也只對應到那一台主機的資料。
Symphony 在根目錄下的 .gitignore 中就忽略掉了 manifest 目錄，但我們建立的「鏈結」卻會被追蹤。我們的目的是讓每一個 manifest 目錄都被 Git 追蹤，這樣當程式被部署到每一台主機時，就可以在那裡建立該主機專用的鏈結，對應的配置檔案準備妥當、立即可以運作。因此，為了要忽略掉 manifest 鏈結，編輯根目錄下的 .gitignore 檔案，在 manifest/ 下加入另一行 manifest。
打開終端機，追蹤那些 manifest 目錄並提交
git add manifest.*
git commit -m 'Added manifest folders'
git push mywebsite
當我們在開發主機（dev）上安裝 Symphony，系統會在 manifest.dev 目錄下建立各項必要的運作與暫存檔案，配置檔（config）也會被建立，這是唯一一個需要拷貝到其他 manifest 目錄的檔案。當你準備將程式推到另一台主機時，只需要複製 config.php 檔案、修改資料庫的設定。
安裝 Symphony 實在簡單，參考 Symphony 官網上的資訊即可順利安裝（其實看到安裝畫面你就會了，連文件都不需要看）。