1 - 由于每次開發(fā)時(shí)，都需要更改相關(guān)文件（項(xiàng)目的特殊性，env文件和debugger工具特殊使用方式，以及有些功能在模擬器中無法正常運(yùn)行，只能代碼跳過），為了不用每次頻繁更改
我把一次更改好的內(nèi)容建立了一個(gè)分支叫做 microl/editFilesForDev 并且提交了 commit，
commit id 為：06c4ee71f102308f4ced9476766c2dea22d628ba

以后每次開發(fā)新任務(wù)時(shí)，只需要先把這條commit 通過cherry-pick指令摘取到新分支上便可直接進(jìn)行開發(fā)了，不用重復(fù)修改那些文件了

實(shí)際案例：

比如，我現(xiàn)在處在一個(gè)叫做AAA-SSS的項(xiàng)目上，并接到一個(gè)new task，該task在 DevOps 上建立的 ticket 為 【453234 — [AAA] xxx UI need to change】
那么我在平時(shí)開發(fā)過程中會涉及到的git操作一般有：
（1）切換到主分支 git checkout master ,然后拉取最新代碼 git pull
（2）base 主分支(最新)來創(chuàng)建并切換一個(gè)新分支：git checkout -b fix/AAA-SSS-453234；注意-我現(xiàn)在已經(jīng)切換到新分支上了,然后就能把提前準(zhǔn)備好的開發(fā)文件commit cherry-pick 過來了：git cherry-pick 06c4ee71f102308f4ced9476766c2dea22d628ba；這個(gè)commit id就是上面提到的那條,(然后記得要reset到該分支的前一條最新commit，確保這條開發(fā)臨時(shí)更改的commit是處于未提交的狀態(tài))
（3）開發(fā)之前要記錄下當(dāng)前最新的一條commit id，比如記錄下這條commit id — 72a2dba4af7d1005f211cf1381652ec66d5968a4

（4）因?yàn)樾薷拇a過程中，我很可能為了記錄自己的修改記錄，頻繁提交很多commit，但是這在提交PR的時(shí)候是不被允許的，如此一來我在最后提交PR的時(shí)候就能通過 reset 指令回到最出記錄好的 commit 上：git reset 72a2dba4af7d1005f211cf1381652ec66d5968a4，然后重新提交一份完整的新的 commit: [1] - git add . => [2] - git commit -m “fix: 453234 — [AAA] xxx UI need to change”;
（5）這是就會把之前我頻繁提交了好多條的commit記錄都給覆蓋掉了，現(xiàn)在就只會只有一條剛提交的最新的commit了
（6）強(qiáng)制推送到遠(yuǎn)程分支上：git push origin fix/AAA-SSS-453234 —force; 因?yàn)橹伴_發(fā)的時(shí)候，我很可能我已經(jīng)把commit記錄都推送到遠(yuǎn)程分支上了，因?yàn)楸镜乇４娌灰欢煽?萬一電腦出問題了)，那么此時(shí)本地分支和遠(yuǎn)程分支的commit就會不一致有沖突，所以我需要使用 —force 指令來把本地分支的強(qiáng)制推送到遠(yuǎn)程分支上
（7）這樣一來最后提交的PR就只會看到只有一條commit了，review代碼的人就不會說什么了