CakeDC Git workflow是一個專案開發和版本釋出的工作流，在這個工作流程中開發和版本釋出週期是基於幾個關鍵階段(key phases):
- Development:
所有活躍的開發活動都由里程碑驅動，在這個階段的產出是很不穩定的程式碼基線
- QA：
Quality assurance testing作為一開發週期的一部分，主要協助確保需求的滿足性和質量的可接受性
- Review
客戶或者評審員面對的是一個穩定的程式碼基線，該基線已經經過了QA流程，質量上已經被QA人員認可
- Release
釋出版本在QA和review評審流程都順利完成之後的產物。
cakeDC所使用的workflow設計是基於vincent driessen的gitflow推薦，雖然他們有一些相似性，但是也有部分的裁剪和修改，可能更加適合於較大型團隊，有正式流程的專案開發
Organization：
本workflow設計的主要思想是它能適合於整合一個QA流程作為他們開發流程一部分的團隊或公司，同時給客戶提供一個穩定的stage server來review和approve the pending release。然而，如果你沒有QA流程，或者不提供stage server for customer review/approve，這些步驟也可以輕易地被忽略。
貫穿各個phase我們專案的整個開發和釋出被劃分為幾個不同階段的目標，我們稱之為milestones。一個milestone本身並不等同於一個release.一個專案的一個版本可以由多個milestone構成，這依賴於專案的計劃和資源狀況。
這些phases由"permanent永久"和"temporary臨時"的分支來代表，通過這些phase，推進我們的開發流程向一個release的正確方向邁進。需要一個持續性的分支的原因是為了準備各種部署需求，允許每一個人在專案開發不同階段產品的狀態有一個清晰地認識。這兩種分支包含下面的git branches,而這將形成我們的work flow的一部分。
Permanent braches:
1.develop
也被稱為bleeding edge（前沿）,這個分支包含為當前milestone準備的已經結束的features。這是一個alpha狀態的程式碼基線，往往被認為是非常不穩定的。
2.qa
所有為了一個milestone而做的開發活動最終在這個分支上來做驗證和測試。這是一個beta階段的程式碼基線，也被認為是不穩定的。
3.stage
一旦為了一個milestone做的開發工作通過了QA測試，那麼就可以用這個分支來host stable code base for review.
4.master
如果上述stage分支的程式碼由客戶或者評審人員approval了，那麼stage分支的程式碼就merge到master,而這個master分支將在生產環境保留專案的當前穩定版本。
Temporary branches:
1.feature
這些分支是從develop分支上建立出來，目的是為了隔離一個特定任務的開發工作。feature本身的定義往往很大程度上與管理風格有關，比如milestone是一個長的或短的sprints。
2.issue
這些分支從qa分支上建立，目的是為了解決完整測試一個milestone的軟體的QA階段報出的問題
3.hot-fix
這些分支是由生產環境中報出的緊急問題而觸發的。最好的情況下，這些分支將永遠不會建立，因為我們經過QA流程，質量得到了很好的保證
“永久”和“臨時”的分支的重要區別是：對於permanent分支，永遠不會在這個分支上直接修改程式碼commit程式碼，永久分支上永遠是通過merge臨時分支而得到相關程式碼的。完整的流程如下：
在下面的章節中，開發和版本釋出的各個階段phases將會分別描述，詳細講解各個流程
Development:
在一個milestone的實際開發活動中，開發人員將從develop分支建立feature branch
這些分支命名為"feature/xxx"。xxx通常對應著專案管理系統中的一個ticket，比如
$ git checkout -b feature/1234 develop $ git push -u origin feature/1234
通過將開發任務隔離到一個獨立的分支上，開發人員能夠有效避免destablize develop分支，以免影響他人的工作。而且，如果有些feature是基於其他的feature，那麼這個feature分支可以被其他已經commit到develop分支的feature做updated(rebase)
如果你和其他的開發人員在做同一個feature，那麼你可以checkout他們的分支，並且協同工作。
$ git checkout -t origin/feature/1234
當一個feature開發結束，它將被merge back to develop分支，feature分支本身可以被刪除了。
$ git checkout develop $ git merge --no-ff feature/1234 $ git branch -d feature/1234 $ git push origin :feature/1234
develop分支本身本認為是不穩定的，所以最好開發人員能有一個部署這個branch的伺服器，這樣他們能夠輕易地修改專案的bleeding edge version of the project,輔助討論或者提供一個review當前進展的方式。這也幫助那些對開發流程不是非常清晰地專案經理獲取到將要到來的milestone的真實狀態。
Testing:
當一個milestone被認為完成時，develop分支將被merge到qa分支，QA流程啟動：
非常重要一點：當develop分支被merge到qa分支時，所有的新features將構成了下一個milestone.這就允許對當前milestone的測試和對下一個milestone的開發工作完全並行化了。另外，由於QA流程是在一個專用的branch上進行的，這就允許測試階段可以在不影響繼續開發的前提下來做規劃和執行。
$ git checkout qa
$ git merge --no-ff develop
在測試階段，QA可能發現這個milestone的一些issues，也就是說有些feature是fail掉的。當這種事情發生時，為了解決這些bug我們將要從qa分支上來建立issue分支。這些分支被命名為"issue/xxxx"，xxxx代表了你的專案管理或者bug tracking系統中的一個id，比如：
$ git checkout -b issue/1234 qa $ git push -u origin issue/1234
當這個issue branch存續期間，如果這個問題本身依賴於另外一個issue的結束，那麼這個issue branch本身也可以被其他已經被commit到qa分支上的其他issue的commit來做updated/rebased。當問題解決了，merge到qa分支，然後這個issue分支就被刪除了
$ git checkout qa $ git merge --no-ff issue/1234 $ git branch -d issue/1234 $ git push origin :issue/1234
在QA階段，一個專用的測試伺服器應該是必須的。這個伺服器部署qa分支的程式碼，專門用於QA團隊來做測試使用。
Review:
一旦一個milestone貫穿了實際的開發活動，並且完成了QA流程，新的功能現在就可以放到stage分支上做review了。
在這裡qa分支將被merge到stage分支上，同時qa分支也需要merge到develop分支上去，以便為將來的milestone來使用：
$ git checkout develop $ git merge --no-ff qa $ git checkout stage $ git merge --no-ff qa
而且，為了標示milestone的結束，應該從stage分支上打一個tag,這些tag被命名為"milestone/xxxx" xxxx是一個milestone id，通常就是一個序數。
$ git tag -a milestone/1
stage分支現在可以部署到一個staging server上去了，可以邀請客戶或者評審人員來review和評審。如果任何問題被發現或者新的功能在這個時間被要求，那麼他們就將成為在develop分支上的當前active milestone的開發任務，或者可以計劃到將來的開發任務中去。
在qa或者stage分支上，不允許直接修改commit，只允許通過feature分支merge到develop分支，隨後通過QA流程。尊重這個流程非常重要，然而可能很多組織就直接在stage分支上打patch了，因為這將破壞QA流程。
Release：
當stage分支通過了review，在完成一個或多個milestone之後，一個release可以被建立了。這將是更新生產伺服器程式碼的
時
機了。
為了建立release，stage分支需要merge到master，另外，為了建立一個release，一個tag需要再master分支上打上。這些tags命名為"release/xxx" xxx為version number。
$ git checkout master $ git merge --no-ff stage $ git tag -a release/1.1.0
所有在本release之後從qa merge到stage的程式碼都構成了下一個版本的應用。
Hot Fixes:
在生產環境中，有時可能會發現一些重大問題，而使用者又不能等到下一個release來解決，這時就需要用到hotfix了。
在這種情況下，一個hot-fix分支需要從master分支上建立，這些分支被命名為“hot-fix/xxx"xxx為bugid：
$ git checkout -b hot-fix/1234 master $ git push -u origin hot-fix/1234
依賴於QA的需求，可能需要再問題解決後，就在hot-fix分支上來做驗證。有3中方法：
1.Kamakazee: 這裡hot-fix分支被merge到master分支，QA直接在生產環境中測試。這是不好的方式，因為資料的不一致性可能導致問題
2.Copycat:這裡hot-fix被merge到master，而master分支本身被staged到一個專用的伺服器。如果生產環境是基於pushes to the repository or a scheduled build來自動部署的，那麼
這就可能是不可能的。
3.Paranoid:這裡hotfix分支staged on a dedicated server，QA必須評審測試，之後才能merge到master。那個staged server有可能需要replicate the data used in the production environment。但是如果由於法律問題或者資料私密問題，也可能不可行。那麼一個可選項就是直接stage on the production itself.
一旦patch本身成功了，the hot-fix分支必須merge到stage,qa,develop分支上去。
$ git checkout master $ git merge --no-ff hot-fix/1234 $ git checkout stage $ git merge --no-ff hot-fix/1234 $ git checkout qa $ git merge --no-ff hot-fix/1234 $ git checkout develop $ git merge --no-ff hot-fix/1234
However, depending on the length of the milestones, it's possible that sufficient changes have been made in the pending release that the problem found in production has already been rectified, or the functionality surrounding the issue has been modified to a point where the problem no longer exists, or has been altered completely.
Finally, once the hot-fix has been applied to all the relevant branches it can now be removed.
$ git branch -d hot-fix/1234 $ git push origin :hot-fix/1234
If you find that there are numerous bugs in your production environment this can be attributed to insufficient details at the requirements stage of the project, or an inefficient QA process. Keep in mind that the QA process is only as good as the initial criteria, so validating the specification for a project is key to it's success.
It's also worth noting that any developer who creates a "temporary" branch should remain responsible for it, as they are the most likely candidates to know the status of the branch.