首先列一下我所看到的git分支管理：
其中：中間的Origin代表的是遠程分支，Native代表的是程序猿自己本地的分支绰姻。
這種常見的分支管理方式很普遍枉侧，但是同樣，我認為也沒有用到點上狂芋，是處于最低端的榨馁，git的用法可不僅僅在于這些。
首先帜矾，我先繪制一下我所說的相對標準的git分支管理方案：
接下來我會以騰訊工蜂系統(tǒng)對以上步驟詳細解讀一下(Origin代表的依舊是遠程分支翼虫，Native代表的依舊是程序猿自己本地的分支)：
- 步驟1:基于master檢出遠程分支的dev.1.0分支,這個dev.1.0為1.0版本的總分支（這個比較簡單，略過）
- 步驟2：主管對遠程分支的dev.1.0進行加鎖屡萤，如下圖：
騰訊工蜂系統(tǒng)某一分支頁面
其中：點擊左1紅色框可選擇某一遠程分支珍剑，左2紅色框為當前的分支（dev.1.6.2），左3紅色框為加鎖按鈕灭衷。
點擊左3紅色框的加鎖次慢，可以看到：
點擊底部綠色“創(chuàng)建鎖”即為創(chuàng)建鎖成功。（看下上圖對于鎖的描述與目的翔曲，這是很重要的思想）
步驟3：基于遠程分支的1.0總分支迫像，創(chuàng)建屬于自己的遠程分支，之前的規(guī)則為dev.1.0.程序猿名字簡寫或全拼
步驟4：團隊下的程序猿將自己的遠程檢出到本地
步驟5：提交自己代碼到遠程分支（直接push瞳遍，沒必要執(zhí)行pull等操作）
-
步驟6：因為步驟2加鎖的緣故闻妓，并不是所有人都有對dev.1.0的修改權限，所以在git地址上掠械，創(chuàng)建一個merge請求由缆，目的是將自己遠程分支上的代碼合并到dev.1.0這個版本總分支上注祖，同時艾特同組人員進行代碼審核，如下圖：
創(chuàng)建merge請求頁面
點擊左側紅色框均唉，后再點擊右側紅色框是晨，則如下圖：
選擇源分支和目的分支(注：當前是以dev.1.7.0.lc為源分支，目的分支是dev.1.5,忽略這個細節(jié)）
點擊左下角的“比較兩分支”舔箭，若有未merge的代碼罩缴，則會跳轉(zhuǎn)到如下頁面（這個頁面數(shù)據(jù)較多，以下三張圖片連起來則為當前頁面的全部功能）：
鑒于代碼安全方面的考慮桶至，就不截圖代碼“變更”記錄了。
- 步驟7：在Origin:dev.1.0分支上打包扒袖，提交審核之后塞茅，蘋果審核通過之后，Origin:dev.1.0再創(chuàng)建一個merge請求（參考步驟6）季率，將Origin:dev.1.0代碼合并到master。這一步驟是為了防止審核不通過描沟，導致master代碼與app store的功能不一致飒泻。
最后說下這套分支方案的優(yōu)點：
高效性。很多人會疑問：這套方案看起來復雜吏廉，哪來的高效性泞遗？其實不然。原因在于步驟3和步驟4的存在席覆，我只關心我自己的功能史辙，其他人提交了什么我不管。如果按照文章開始的那套分支方案佩伤，其他人提交了代碼聊倔，我在提交時，大概率上還要拉取遠程分支生巡，最終會導致再次編譯耙蔑，這點我是難以忍受。項目大了孤荣，人員多了甸陌，耗費的時間會翻倍增長须揣。
流程規(guī)范。包含了git相關的所有功能钱豁，比如遠程分支耻卡，本地分支，pull牲尺，push劲赠，merge等。
安全性秸谢。安全性包含了兩方面：1.步驟2的遠程分支的加鎖凛澎。2.步驟5的本地分支代碼的隨時提交，比如中午吃飯估蹄，抽煙塑煎，開會，下班等出現(xiàn)離開電腦前的情況時臭蚁，隨時將本地代碼push到自己的遠程分支最铁，保證本地分支的代碼與遠程分支始終保持一致，即使是功能未完成垮兑，跑不起來也要提交冷尉，提交之后也不會影響其他人編譯他們自己的分支上的代碼。
當然系枪，正如文章標題所說雀哨，這套分支方案是相對標準，有一定缺陷私爷。隨著知識點的增加與編程思想的夯實雾棺，我心目中也有一套絕對標準的分支管理方案，后續(xù)有時間我會更新衬浑。
