大話 Git 工作流

作者：wzw@Coding.net

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

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

但是今天他們又開了一個新的話題，那就是程式碼託管的工作流。

小劉率先發言，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 工作流。

原文地址：https://blog.coding.net/blog/git-workflow