Git作為一個目前非常流行的版本管理工具，深受開發(fā)者的喜愛。那么怎樣才能將Git的作用發(fā)揮的更好呢？我根據(jù)實際的項目經驗，歸納總結了以下Git工作流的最佳實踐。這里所謂的最佳，是經過多次項目經驗后，根據(jù)自身的情況總結出來的我認為最為合理的方案。

Git工作流的最佳實踐方案包括如下四個步驟：

1. 根據(jù)task創(chuàng)建對應的branch

當我們開始針對一個task編碼之前，首先第一步應該要創(chuàng)建一個新的branch，然后checkout到這個新的branch上開始編碼。我們不應該直接在master上進行新的task的編碼工作，尤其是在團隊成員較多的情況下。團隊的每個成員都應工作于自己新創(chuàng)建的branch上，而不會操作master分支，這樣做的好處在于master始終處于一種“干凈”的狀態(tài)，不會因為多人的同時操作而造成過多的沖突，同時也降低了master被誤操作的可能性。具體的操作如下：

//切換到master分支； git checkout master //拉取master遠程分支的代碼； git pull origin master //創(chuàng)建新的分支并切換到新的分支上。 git checkout -b <my branch name>

?

2. 在新建的分支上編碼，push代碼到遠程分支上

分支創(chuàng)建完畢之后，我們就可以開始在branch上進行編碼了。這是我們完成task的最主要的階段，絕大部分的工作在此階段完成，同時它應該也是持續(xù)時間最長的階段。它的主要任務就是完成task的編碼工作，并最終將代碼push到當前分支對應的遠程分支上去。

首先看一下這個階段Git工作的命令流，示例如下：

//創(chuàng)建新的branch后的第一天工作結束時，首先將改動的代碼放入index區(qū)； git add . //然后提交代碼到本地倉庫； git commit ?-m "The first commit message" //第二天開始工作前，切換到master分支； git checkout master //從master的遠程分支拉取代碼； git pull origin master //切換到task所在的本地分支； git checkout <my branch name> //將master上的最新的代碼合并到當前分支上，這里的-i的作用是將我們 當前分支之前的commit壓縮成為一個commit，這樣做的好處在于當我們之后創(chuàng)建pull request并進行相應的code review的時候，代碼的改動會集中在一個commit，使得code review更直觀方便； git rebase -i master? //第二天工作結束之后，將第二天的改動放入index區(qū)； git add . //提交代碼到當前branch的本地倉庫； git commit? -m "The second commit message" //第三天開始工作前， git checkout master //同上第二天 git pull origin master //同上第二天 git checkout //同上第二天 git rebase -i master? //同上第二天//第三天工作結束之后， git add . //同上第二天 git commit? -m "The third commit message" //同上第二天

..........

//最后，當task的所有編碼完成之后，將代碼push到遠程分支。 git push --set-upstream origin <my branch name>

通過以上的工作流可以看出，我們在完成task期間所有的代碼都始終存放在我們新創(chuàng)建的branch的本地倉庫上。只有當所有的編碼工作完成之后，才會將最終的代碼push到當前分支的遠程倉庫。這樣做的好處在于，我們push到遠程的代碼，也就是之后會通過pull request被code review的代碼，始終是針對一個單獨task的完整代碼，這將有利于之后code review的執(zhí)行。不過這樣做同時可能會存在一個缺點，那就是最終一次push的代碼可能會非常龐大，這就要求我們對于task粒度的把握應該更合適。我們不應針對一個非常大的task創(chuàng)建branch，完成編碼，而是應該盡可能的將task分解成一個個粒度較小的子task，進而針對子task創(chuàng)建branch完成編碼的工作。這是一項非常有技巧的工作，需要豐富的實踐經驗，它也不是本節(jié)要討論的內容，不再贅述。
?

3. 創(chuàng)建pull request, 進行code review

當所有的代碼都已經被push到遠程分支后，這時我們還不可以將代碼合并到master上去，我們應該要做的是創(chuàng)建pull request。pull request的作用在于它可以使得代碼在merge到master分支之前，能夠被團隊成員code review，從而提高代碼的質量以及降低出錯的概率。實際項目中我們使用jira來幫助我們創(chuàng)建相應的pull request，當然Github本身就具備創(chuàng)建pull request的功能。創(chuàng)建pull request的操作非常簡單，無非就是點擊創(chuàng)建pull request的按鈕，填寫comment信息，并輸入可以進行code review的成員名稱。當pull request創(chuàng)建完成之后，所有可以進行code review的團隊成員都會收到郵件通知，并通過相應的pull request的鏈接查看代碼的改動，從而完成code review的工作。這個步驟沒有實際的Git指令的操作。
?

4. 合并代碼到master，并刪除之前創(chuàng)建的branch

當所有的reviewer都結束了code review，且都已經將pull request標注為approved狀態(tài)的時候，我們就可以將branch合并到master上去，并最終push到遠程master分支。示例如下：

git checkout master //切換到master分支； git merge <my branch name>//合并之前創(chuàng)建的分支的代碼到master分支上； git push origin master//將master的代碼push到master的遠程分支； git branch -d <my branch name>//刪除之前創(chuàng)建的分支。

經過以上四個步驟之后，一個task的 Git的工作流就結束了。之后，我們可以愉快的開始下一個task了～～

總結

以上是生活随笔為你收集整理的Git工作流程最佳实践总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。