大話 Git 工做流

原文： https://blog.coding.net/blog/git-workflow
做者：wzw@Coding

深圳的秋天，比全國大多數地方都來得更晚。在通過忽冷忽熱的掙扎中，天氣漸漸轉涼。
這天是週末，晚上天氣涼爽，小劉，小李，小高，小陳四我的，約好一塊兒來擼串。他們是大學同窗，學的是計算機，畢業後都到了深圳，目前都以寫程序爲生，加入了程序員大軍。

程序員的聚餐節目是固定的，幾口大腰子下去，再加上幾杯啤酒下肚，幾我的不約而同的開始各類吐槽，從罵老闆，罵上司，罵產品，罵設計，罵到最後，你們都懂。所謂的程序員的聊天以罵老闆開始，以撕編程語言結束。

可是今天他們又開了一個新的話題，那就是代碼託管的工做流。

小劉率先發言， git 這貨 跟 svn 沒啥差異，我一向仍是按照以往的，寫完了就提交，咱們三五我的的小團隊也都這樣，除了能夠在本地不連服務器上也能提交代碼這點以外，跟 svn 沒啥差異，咱們就只有一個主分支跟 svn 的主幹是同樣的，你們都在這上面工做，團隊協做溝通很是高效。

小劉所講的工做流 -- Centralized Workflow



這套流程講究的就是快速，簡單，這對於大多數我的開發者和小型團隊來講是最好的選擇，每每是維護一個 App ，我的博客，或者一個小型網站之類的。總結下來適用場景和基本特色是：


1. 團隊人數少

2. 開發不是很頻繁

3. 團隊溝通方便

4. 不需同時維護多個版本

繼續說回咱們的故事。
小陳聽不下去了，說道：咱們團隊都推行使用一個 git 的插件，叫作 git-flow ， 全部成員，都按照這個軟件規定的標準流程進行協做，每次改動，咱們都根據不一樣的情形，使用 git-flow 工具來新建相應的流程。你們都按照這個流程來，雖然繁瑣，可是咱們三十幾個開發團隊共同維護幾個項目，歷來都是運行平穩，從未出事，就大家那幾我的三天兩頭代碼庫被新手搞亂，竟然還好意思叫團隊協做溝通高效？我看是搞笑吧，哈哈。

小劉氣的臉通紅，又沒啥話好說，只好忍了。

小陳所講的工做流 -- Git-flow Workflow



這套工做流講究的是平穩，有序， Git-flow 工做流在 Git 分支標籤等概念的基礎上，添加了一些 Feature ， Release ， Hotfix 等概念，用以精確描述代碼版本控制的一些流程，全部協做者在放棄一些我的效率的基礎上，統一開發流程，最終帶來的是總體的規模化的團隊的總體效率提高。其缺點是上手較難一點，須要一些基礎知識培訓，適用場景以下：

1. 認爲額外學習 Git-Flow 不是什麼問題的

2. 有專門的代碼倉庫管理員的

3. 開發團隊相對固定，並且有必定規模

4. 經常有並行開發需求

5. 團隊對於 Release ， Bug ， Feature 這些概念有統必定義標準的

繼續說回咱們的故事。
這時小李淡定的拿出一串羊肉，吃了一口，說道：我不知道大家說的是什麼玩意，可是我做爲一個自由職業者，維護着一個開源軟件，平時也給一些開源軟件貢獻些代碼，歷來都是 Github 上 fork 完了，再提交 Pull Request 的， Pull Request 會被開源軟件的維護者評審，若是評審經過，就會合併到源項目。我做爲一個開源軟件的維護者，既評審着別人給個人貢獻，也貢獻給別人評審，這是一個很是理想的生態循環，我不知道大家扯那些破玩意有啥用。

小李所講工做流 -- Fork Workflow



這套流程是專門爲開源軟件量身打造的一套流程，最先的發明者是 Github ， Github 是世界知名開源軟件倉庫。這個流程的最大特色就是，開發參與者能夠不直接參與到項目中來，想貢獻代碼，只要 fork 目標項目後，就能夠獲得一個如出一轍的自有項目，作完修改後，提交 Pull Request 給原項目，如原項目的維護者採納了，即算貢獻完成。圖中看一看到，每一個開發者（團隊）都擁有本身維護的一個項目，跟別人項目之間的聯繫經過 Pull Request 形式解決。總結下來適用場景是：

1. 經常使用於開源軟件

2. 開發者有須要衍生出本身的衍生版的

3. 開發者不固定，多是任意一個網友

繼續說回咱們的故事。
小高是個胖子，每次擼串最能吃，基本上聊天的時候都是偶爾插一句話。可是這時候，聽完這一頓撕，也忍不了了，用紙巾擦掉嘴上的辣椒說道：咱們公司，跟大家選擇的都不一樣，咱們公司使用基於 git-flow 簡化的一個模型來協同工做，不須要安裝什麼 git 插件。版本庫有一個默認分支 master ，須要 release 的時候，就將默認分支打一個標籤，用做 release 。使用 Coding 提供的保護分支功能， master 指定若干管理員，其餘人有任何修改都在默認分支 master 的基礎上新開分支，提交代碼，而後到 Coding 上向 master 提交合並請求，並能夠指定若干團隊成員做爲評審者，評審經過後就能夠合併到 master 上了。也歷來都運轉平穩，從未出事。

小高所講工做流 -- Feature Branch Workflow



這套流程屬於 Git-Flow 的簡化版，再也不須要安裝額外 Git 插件，基於代碼託管平臺提供的一些基礎功能來實現，主要流程分 Feature 流程和 Bug 流程。這個流程是適用於大多數團隊人數在 5 人以上，有不少並行開發需求，切更新頻繁，開發任務重的協做團隊。其適用場景是：

1. 開發團隊相對固定，並且有必定規模

2. 經常有多個功能，多個問題並行開發

3. 對代碼審查有較高要求

4. 更注重團隊效率

小劉，這時才從小陳的話中緩過神來，對小陳說道，咱們雖然是出過新手搞亂了代碼庫的問題，可是 git 都是有歷史的，並不是不可恢復，關鍵是咱們流程簡便，歷來有任何問題都是快速響應，不像有些公司，修個 bug ，竟然要等一週才能上線。

小李又說道，有啥好吵，都是沒啥卵用的玩意，你就按照 fork / pull request 來搞就好了。

你一句，我一句，七嘴八舌的，吵得不可開交。
。。。。。。

這四位的爭論愈來愈激烈，沒辦法，程序員的爭論都是撕破臉皮，面紅耳赤，直至燒烤店快要打烊了。最後驚動了燒烤店的老闆娘。老闆娘聽罷爭論，笑眯眯的走過來講：年輕人莫要激動，我雖然不知道講什麼，但這世間萬物，都有適用範圍，沒有什麼是絕對好的，也沒有什麼是絕對壞的。就比如大家吃燒烤的辣椒，放在這烤肉上，味道就很是不錯，可是你見過哪家冷飲店放辣椒的麼？

幾人聽完，瞬間以爲衛生阿姨就比如金庸小說掃地僧那般神奇，細思恐極，趕忙結了帳，匆匆離開了。

============ 這是分割線 ============

是啊，沒什麼是絕對好的，也沒什麼是絕對壞的，每樣東西都有適用範圍。

以上，適用場景並不定死，是靈活多變的，甚至於咱們能夠超出以上四種模型，取其精華，棄其糟粕，本身創造出新的模型來。總之，但願這篇文章能幫助你找到屬於符合本身的模型的 git 工做流。