目前開發的專案採用git作為版本管理工具，
平時開發有兩個分支，develop和master
在develop上開發，
在master發布正式版本。
目前有這樣一種情況：
有一個設計好的功能，由於種種原因，在develop分支上開發完成後不能正常使用，
需要使用另一個補救性的設計方案臨時代替，此代替方案需要上線，發佈到master裡面
當原功能成熟後，再刪除這個補救方法，切換回原有的功能
請問我該使用哪一種git分支策略？
我想大声告诉你2017-05-02 09:22:14
推薦Gitlab flow中的merge request方式
master, develop分支都是不讓直接push的
master = production
develop = next release
當有新需求時，建立需求分支 feature/aaa
開發完成後建立 merge request
code review 後合併 feature/aaa 到 develop 分支
上線時合併 develop 分支到 master
發布 master 分支
對於樓主的問題可以這樣
基於 feature/aaa 建立新分支 feature/bbb 完成補救工作後合併到 develop, feature/aaa 建立新分支 feature/bbb 完成补救工作后合并到 develop, master 然後上線
繼續 feature/aaa 的開發工作，最後合併到 develop, feature/aaa 的开发工作，最后合并到 develop, master
PHP中文网2017-05-02 09:22:14
可以參考 git workflow
大致就是 從 master分支checkout一个hotfixes分支。在hotfixes把补救的写好，然后分别merge到master和develop。此时就可以删除这个hotfixes分支。
然後再從develop分支开发完善你的功能，最后把develop分支merge到master上線。
或許還有更好的方法，僅供參考
phpcn_u15822017-05-02 09:22:14
先幫樓主解決這個問題。
樓主的分支策略不用做特殊處理，按照正常的流程，結合 git 的功能即可處理的很好：
依照我的理解，樓主所說的「原功能」、「補救方案」這些都是正常的代碼提交。樓主所困惑的應該是臨時補救方案最終要被丟棄（回滾）這個問題如何處理，所以使用上面提到的 git revert 命令應該能滿足樓主的預期。這樣既能保證所有的對程式碼庫的操作都可以被記錄在主幹（master、develop）中，也避免了複雜的分支模型等問題。
另外，不知道樓主使用的分支策略是不是 按照 @rsj217 提到的 workflow 來做的。如果 develop 是所有開發人員的主要開發分支的話，我覺得 develop 最好還是不要接受未完成的開發特性直接提交比較好。在日常的開發工作，尤其是在多特性/分支並行開發的情況下，多個特性分支能避免彼此之間的干擾。
回到樓主的問題上來，這個不能使用的設計方案可以繼續開發，不要合併到 develop 上去。基於這個分支 checkout 一個補救特性的開發分支，測試完成後合併到 develop 進入發布流程即可。後面的 merge 和 revert 建議還是要的，非迫不得已不要違背流程做特殊處理，而且這樣保留了所有的程式碼commit操作。
高洛峰2017-05-02 09:22:14
姑且說你的補救分支是develop1，上線之後develop1和master會merge到一起變成了新的master,原功能的分支develop等成熟穩定之後merge下新master（很大可能會衝突）,把develop1的那部分刪掉，測驗沒問題上線。有點麻煩，可能還有點笨，可是git每次merge都是向前產生了一個新的點，你要是想等develop穩定了把master回退，如果中間有其他發布了，不久丟東西了麼。
或許還有更好的方法，僅供參考