今天看到阮一峰寫的《git分支管理策略》，覺得挺好，決定在團隊內部試行一下。
我們團隊屬於人少，專案相對較多，同乙個專案版本也多。有新功能演示，需要上線的穩定版，不同客戶之間功能有差異的版本，此外專案之間還有整合的問題。所以長期以來版本非常混亂，恐怕沒幾個能很清楚的說出哪個版本的功能集以及針對的客戶，qa也不知道。
原文中提到乙個git flow的管理策略模型，如下所示：
結合該模型，簡單設立了一下團隊內部的開發過程。關鍵在於，第一團隊要認可這種模型，第二團隊對於發布計畫要很清楚。
1. 設定基本的發布計畫。即確定好master的幾個production版本的時間點，如圖上master的幾個tag。
2. 設定迭代計畫。即確定好release上的主要tag時間點。
3. 將每個story拆分成粒度合理的task。團隊需要認可push到develop上的commit，原則上應該是個完整的task或者bug。這裡我把task當成feature，各個相互配合的開發人員應該以完成整個feature為目標在相應的branch上協作。
4. 到達迭代的測試時間點時，release從develop上merge合適的commit（理想情況下應該就是當前develop最新的commit），構建版本後進行測試。如果有重大bug，該版本應該予以撤銷。
5. 同時，在使用git構建時，應該新增自動功能（可以使用buildr等自動構建工具），將當前版本涵蓋的feature、commit等主要內容，自動發布到redmine的專案頁，以便自動追蹤。
6. 如果release有bug，需要fix，並merge到develop上。
7. 到產品版本發布時，從release上將經過測試的版本merge到master中。
8. 開始下一輪迭代。
ps：今天上海大雨。
關於Git的一點思考
很多人都知道，linus在1991年建立了開源的linux，從此，linux系統不斷發展，已經成為最大的伺服器系統軟體了。linus雖然建立了linux，但linux的壯大是靠全世界熱心的志願者參與的，這麼多人在世界各地為linux編寫 那linux的 是如何管理的呢？事實是，在2002年以前，世界...
多專案管理的一點思考
與人閒聊，被問到如何去同時管理多個軟體專案，討論思考有三 第 一 制度化，多個專案進行，勢必會分散人的精力，在有限的時間如何把這些工作做好，通過規範化的制度，各個專案的文件，進度都應該做到去規範，制度化。第 二 專案進度的掌控，軟體專案最重要的是進度難以考核量化，從每個人不同的角度去看待專案，所得到...
遞迴的一點思考
廢話不說，直接上 searchtree delete int x,searchtree t else if t left null 沒有兒子的情況也包含了，因為t right 為null else else if x t element t right delete x,t right else t...