新需求->開發(fā)->測(cè)試->pr->新需求....在旱，應(yīng)該是大部分寫業(yè)務(wù)的程序員的日常了（架構(gòu)師除外）。本文主要講pr這一小步雷蹂，也是作者痛定思痛之后學(xué)會(huì)的一個(gè)小技巧姆怪。
先說(shuō)下背景，自己開發(fā)完之后先將代碼提交到自己倉(cāng)庫(kù)宫屠，然后將代碼部署到beta（測(cè)試）環(huán)境去測(cè)試列疗。當(dāng)然你有可能一次成功，而且也不需要任何優(yōu)化浪蹂。本文主要針對(duì)的是一個(gè)需求提交多次之后才達(dá)到提交pr條件的情況抵栈。
git add xx --> git commit -m 'xx' --> git push origin yourbranch，多次重復(fù)之后代碼終于沒問題（自己感覺）了坤次，于是提交了pr古劲。reviewer檢查之后又給你提出了幾個(gè)需要修改的地方（崩潰）。于是你又馬上修改-->add/commit/push-->測(cè)試缰猴，但是從現(xiàn)在起每次提交都會(huì)給reviewer發(fā)郵件产艾，如果不想讓reviewer因?yàn)槭盏蕉啻胃械絽挓憧赡軙?huì)先把pr關(guān)閉，悄悄地把bug改掉闷堡。但是目前一個(gè)需求已經(jīng)有好多commit了隘膘，這個(gè)時(shí)候你想把這些commit合并成一個(gè)怎么辦？在另外一個(gè)branch上重寫一遍之前的代碼杠览？作者之前就是用這種蠢辦法弯菊，瘋狂復(fù)制粘貼，麻煩而且還不一定能保證沒有遺漏任何之前的修改踱阿。本文就在不重寫之前代碼的情況下幫你解決這個(gè)問題误续。
前提，自己的倉(cāng)庫(kù)至少有兩個(gè)分支branch1/branch2（master除外扫茅，master分支不宜隨便動(dòng)）蹋嵌。假如之前在branch1上add/commit/push 10次之后代碼沒問題了，而且保證branch2上和項(xiàng)目倉(cāng)庫(kù)master分支代碼是同步的葫隙。這時(shí)候git checkout branch2將分支切換到branch2栽烂，然后執(zhí)行g(shù)it rebase（或者merge） branch1，這樣就把之前branch1上的所有提交都同步到branch2上來(lái)了恋脚。注意同步到的是自己的本地倉(cāng)庫(kù)local repository而不是workspace（也就是說(shuō)相當(dāng)于在brabch2上已經(jīng)commit了腺办，還沒有push），可以git status驗(yàn)證一下糟描。這個(gè)時(shí)候branch2上還是有10個(gè)commit怀喉，現(xiàn)在就可以使用git rebase -i將這10個(gè)commit合并了，git push船响，重開pr躬拢，大功告成！
