git git flow 實戰經驗談 part2 - 可能更好的 gitflow 在上一篇 part 1 中指出了 gitflow 帶來的不方便，這篇文章會介紹目前團隊採用的方式，原則很簡單—所有的新增及修正都基於 master 分支。 在開始以前，你必須對 git 有基本的了解，包括 (no-)fast-forward merge 及 rebase 的觀念。
git git flow 實戰經驗談 part1 - 別再讓 gitflow 拖累團隊的開發速度 從一點到另外一點，最快的方式就是直線過去。但有時視情況因為管理的需求，必須要迂迴。因此人們訂定並遵守規範，但對軟體開發來說，不對的開發流程，就只會造成不必要的時間和成本的浪費而已。兩年多以前，寫了「了解 Git Flow」，在實際遵守它進行多人同時開發的兩年之後，我要來指出 gitflow 會帶來的麻煩，以及背後的原因。
程式 了解 Git Flow 當初剛接觸 git 的時候看到這張，只覺得版本控管本來就該這樣作嘛，好像也沒什麼大不了的。真的開始多人開發，加上要出版本的時候，就開始發生問題。最明顯的就是：啊怎麼我的 git source tree 長得這麼亂...如圖這樣簡潔的線條是到底是怎麼長得...。 在釐清比三千煩惱絲還亂的原始碼樹狀歷史之後，有了一些小心得。其實寶藏就在那裡了，只是你沒發現而已。上面這張圖，有一些細節是需要被提出來的。