Java開發從入坑到入溝-Git實戰

Git經典套路

Git代碼管理是技術負責人的必修課。

簡單，清晰的Git管理流程能夠避免小弟們往後無數的妖怪問題

此次代碼到底應該提到哪一個分支啊啊啊33333

我c...個人代碼怎麼沒了？誰幹的!!

老闆，衝突太多了，代碼合不上去啊

哎呀代碼提錯了，怎麼回滾啊（幾百個文件）

......
複製代碼

咱們今天就聊聊如何老練地管理代碼分支（最佳實踐）。

既然咱們是入溝系列而不是入坑系列，Git基礎知識就不講了，若是還不太知道Git是幹嗎的請你們自行百度。

穩定分支

穩定分支是指長期維護的，永不下線的分支，這些分支隨時均可能用來部署各類各樣的環境。

非要舉個例子的話就好比你手裏泡枸杞的保溫杯是穩定分支，給裝修師傅用的一次性杯子是臨時分支。

不要作太多穩定分支，否則你的小弟們會搞不清楚代碼到底提到哪兒。

穩定分支多少算多呢？

若是來了一個新的小弟，你兩分鐘內沒辦法跟他講清楚這整件事情，那麼你的穩定分支就太多了。

穩定分支通常而言是根據你當前有多少套研發環境決定的。

經常使用研發環境有哪些？

dev環境

開發環境。

小弟們幹活的環境，代碼（沒測過的，以及自稱測過的）會部署到這個環境，給測試大兄弟們秀一千零一種翻車姿式。

sit環境

集成測試環境。

若是你的小弟分爲了多個團隊，你可能須要一個集成測試環境，來驗證dev環境測試經過的，各個團隊的代碼能夠友好相處，全部的流程能夠安安穩穩從頭跑到尾。

stage環境

預發佈環境。

這理論上是一個仿生產環境（通常也只是理論上）。這套環境可讓你演練一組功能的上線流程，省得上線磕磕絆絆。測試大兄弟們也會在這個環境作倒數第二遍功能測試。

最佳實踐

爲每個有意義的研發環境分配一個穩定分支。
複製代碼

綜上，你應該有這麼幾個穩定分支：

1. master分支，用來部署stage以及任何生產環境。
2. dev分支，用來部署dev環境。
3. sit分支，用來部署sit環境。注意這個分支是可選的，你能夠壓根兒不要sit環境。

臨時分支

臨時分支是指用過即棄的分支，他甚至不須要出如今遠程代碼庫中，只存在於開發大兄弟的電腦上。

何時須要拉取臨時分支

線上代碼hotfix

這個時候須要從master分支複製一個臨時的hotfix-bugxxxx的分支出來。

全部修改在 hotfix-bugxxxx 完成後，將 hotfix-bugxxxx 合併到master，並部署stage環境，給測試大兄弟驗證。

stage驗證經過後，將master發佈到生產，完成hotfix修復。以後hotfix-bugxxxx臨時分支棄用。

新的須要獨立上線的特性

一樣從master分支複製一個臨時的feature-xxxx 分支出來。

新特性在feature-xxxx開發完成後，將feature-xxxx合併到dev分支，並部署dev環境，開始dev測試（修bug修bug修bug.....）。

dev測試經過後將feature-xxxx分支合併到sit分支，並部署sit環境測試（修bug修bug修bug.....）。

sit測試經過後將feature-xxxx分支合併到master分支，並部署stage環境測試（修bug修bug修bug.....）。

最後把master發到生產環境，新特性上線。feature-xxxx臨時分支棄用。

最佳實踐

每當遇到須要獨立發佈的特性或者bug修復的時候，單獨從master複製一個臨時分支，在臨時分支進行修改。

注意，老是從master複製分支，由於其餘分支中包含了各類不能上線的半成品功能。

複製代碼

Git奇技淫巧

Cherry Pick

Cherry Pick是指將A分支指定的幾個commit 合併到 B分支。老外起名字仍是很是形象的。

通常而言（就是說實際狀況並非這樣的），master分支的特性是最少的，所以按道理老是能夠隨時merge回sit分支或者dev分支。同理sit分支老是能夠隨時merge到dev分支。

可是因爲可能有成百上千個大兄弟分別在有限的幾個穩定分支合併代碼，時間長了這種自上而下的分支合併可能會面臨很是多的代碼衝突。

因此當咱們從master複製了一個featurexxx分支，想要合併到dev分支，給測試大兄弟測試的時候，可能沒那麼容易。

Intelij提供了很是方便的cherry pick 功能！能夠很是方便地把feature分支上，指定的幾個commit合併到dev分支，衝突的機率大大減少！

按期重置dev分支

dev分支雖然說是個穩定分支，可是你會發現時間長了會充斥着不少廢代碼（功能作了一半發現作不下去的，需求取消的，對應功能產品經理離職的等等）。

所以，當每一個迭代開始的時候，技術Leader能夠強制將master覆蓋到dev分支。

git reset --hard xxxx

若是發現提交了錯誤的合併，能夠經過這個命令返回到一個指定hash的狀態。

結合 git push xx:xx -f命令，能夠回滾遠端倉庫的分支hash。

這是大招，請慎用。

多人共用臨時分支

當你的特性須要依賴其餘人的前置開發時，能夠在遠端代碼庫維護一個共用的臨時分支，你們共同在一個feature分支上開發。

Git翻車集錦

請永遠不要作如下的動做。

1. 把dev或sit分支，merge到本地的feature臨時分支，或者本地的hotfix臨時分支。這會讓你的本地分支多出各類別人的代碼，致使你的分支沒法單獨上線。
2. 當遇到代碼衝突的時候，直接刪掉衝突的代碼。這會致使別人的代碼丟失，要去詢問衝突代碼的開發兄弟，爲何他也會改這裏。
3. 分別將相同的代碼修改，單獨貼到master，sit，或dev分支。這會致使大量的衝突。請永遠別這麼幹。代碼只修改一次，而後將修改內容merge到目標分支，不要在每一個分支都修改一次。