有三個人一起開發（例如A、B、C三個人），然後把程式碼都提交到了develop分支上，現在專案要上線，需要合併develop分支上A提交的所有程式碼到mater分支，B、C提交的程式碼不管，這種要怎麼去實現？
首先我得說，這種開發流程是有問題的。
如果ABC是各自開發獨立的功能，那麼他們應該使用自己的分支。這樣管理維護起來就十分方便，也不會有這種奇怪的問題了。
然後，怎麼滿足你這個奇怪的需求：
使用 git log --author=... --format='%H' commit-range 把提交號碼找出來
然後 pipe 到 rev 命令倒個序，再接個循環，挨個把提交 git cherry-pick 到你的 master 分支上
沒有報酬，我也懶得寫具體的命令了。畢竟完整的命令給出來，就得是自己測試過可行的。測試環境弄起來太麻煩。你自己看著文檔嘗試吧。
既然共同提交到develop分支，A 必然會pull B、C的代碼並且merge才能push，兌成一瓶水了怎麼分開？ 唯一的辦法就是看log、diff，手工分開。
既然ABC都已經提交、合併到develop了，那就沒辦法區分ABC了吧？如果確定A的程式碼沒有問題，那麼是否可以直接把A分支裡需要合併的程式碼提交到master呢？
1、把專案從遠端倉庫中，clone下來，放在本地倉庫。 2、在這個檔案的master分支上建立一個與遠端倉庫中A分支同名的新分支。如果你用的是Git，建議使用checkout -b 'A分支名字'：建立並直接進入這個分支。 3、在這個新分支中，從遠端倉庫把A分支pull下來，提交到本地倉庫。 4、切換到master分支，合併新建立的分支，然後提交。
這種具體實現可能有兩種：
就是你們分別在本地拉分支開發，然後不經過develop分支直接從本地合併到master上去(但是應該不會使用這種)，這種就要保證你本地代碼和develop上的一致
另一種就只能B和C把自己代碼線去掉，然後合併
最後，我覺得git類別的這種操作，可能還是要結合你的業務以及開發模式去分析，所以這上面得到的答案不一定符合你們的開發規範。
1.如果A是切分支開發後合併到dev，可以在master合併開發分支中的代碼（假如develop不要BC代碼，可以回撤原來未提交版本號，再合併A代碼，然後master再進行合併）2.如果A是本地開發直接提交dev， 如果提交次數不多，也可在查看log在master中直接cherryPick A提交的條目
首先我得說，這種開發流程是有問題的。
如果ABC是各自開發獨立的功能，那麼他們應該使用自己的分支。這樣管理維護起來就十分方便，也不會有這種奇怪的問題了。
然後，怎麼滿足你這個奇怪的需求：
使用 git log --author=... --format='%H' commit-range 把提交號碼找出來
然後 pipe 到 rev 命令倒個序，再接個循環，挨個把提交 git cherry-pick 到你的 master 分支上
沒有報酬，我也懶得寫具體的命令了。畢竟完整的命令給出來，就得是自己測試過可行的。測試環境弄起來太麻煩。你自己看著文檔嘗試吧。
既然共同提交到develop分支，A 必然會pull B、C的代碼並且merge才能push，兌成一瓶水了怎麼分開？
唯一的辦法就是看log、diff，手工分開。
既然ABC都已經提交、合併到develop了，那就沒辦法區分ABC了吧？如果確定A的程式碼沒有問題，那麼是否可以直接把A分支裡需要合併的程式碼提交到master呢？
1、把專案從遠端倉庫中，clone下來，放在本地倉庫。
2、在這個檔案的master分支上建立一個與遠端倉庫中A分支同名的新分支。如果你用的是Git，建議使用checkout -b 'A分支名字'：建立並直接進入這個分支。
3、在這個新分支中，從遠端倉庫把A分支pull下來，提交到本地倉庫。
4、切換到master分支，合併新建立的分支，然後提交。
這種具體實現可能有兩種：
就是你們分別在本地拉分支開發，然後不經過develop分支直接從本地合併到master上去(但是應該不會使用這種)，這種就要保證你本地代碼和develop上的一致
另一種就只能B和C把自己代碼線去掉，然後合併
最後，我覺得git類別的這種操作，可能還是要結合你的業務以及開發模式去分析，所以這上面得到的答案不一定符合你們的開發規範。
1.如果A是切分支開發後合併到dev，可以在master合併開發分支中的代碼（假如develop不要BC代碼，可以回撤原來未提交版本號，再合併A代碼，然後master再進行合併）
2.如果A是本地開發直接提交dev， 如果提交次數不多，也可在查看log在master中直接cherryPick A提交的條目