看了幾個git的工作流程，感覺都不太符合自己目前的流程。目前我們有三個環境：生產環境、測試環境、本地環境。開發人員在本地開發，push到測試環境，測試人員就在測試環境測試 驗收。
目前我們只有十幾個人的小團隊，沒有一個具體的版本發布流程，所以也沒有到哪天發布什麼版本，哪個任務在什麼時間完成之類的，每個人的工作更像是在做hotfix，做完一個小功能或修復一個小bug就直接推送到develop分支，任務指向測試人員去測試環境測試，沒問題了直接把develop合併到master，發布！ 這個流程在人少的時候還可以，人稍微多一點，就牽扯到 我有個功能要上線了 而另一個功能還在測試階段，master和develop沒法合併，只能等測試結束...
基於功能分支的模式，好像可以解決上述的問題，切一個分支做功能或修復bug，合併到develop去測試，測試通過後合併到master，這時候master就可以隨時推送到生產環境。但另一個問題，團隊裡的成員水平參差不齊，不能讓每個人都有權限合併到master，需要有人去review程式碼，也就是說，合併到master這個操作只能由一個人或幾個人去操作而不是全部，然而可能每天產生的分支就有很多，小到修改一行文字可能都是一個分支，手工去合併這些小分支又是一個很大的工作量.這個跟提交pr的方式有點類似，不夠高效...
有什麼方法能讓測試人員及時看到你的修改方便測試 ，又能隨時隨地的！有選擇性的！往生產環境合併代碼？
仅有的幸福2017-05-02 09:39:28
和我們的工作流程很像，不過我們有規定具體什麼時間出版本，出了版本開發人員再自己的分支上開發，然後在合併的時候想主管發merge-request,主管同意了就到develop分支，然後測試也測develop，測試完沒問題再上主分支。
世界只因有你2017-05-02 09:39:28
我覺得你這個問題很正常,比如A做了一個功能肯定是自己測試沒有問題才能推develop分支然後測試測一下整體功能是否完整,無論誰發這個版本都需要經歷這個過程。如果出現類似develop上有正在測試的代碼,但是現在又有緊急要推的bugfix,一般有兩種做法,一種是把develop上正在測試的代碼cherry-pick出來,一種是用emergency分支。
阿神2017-05-02 09:39:28
git cherry-pick
這個指令可以選擇性的合併提交。通知測試的話，可以設定github在merge之後自動發送郵件到指定郵箱。
git cherry-pick
