大話 Git 工作流
深圳的秋天，比全國大多數地方都來得更晚。在經過忽冷忽熱的掙扎中，天氣漸漸轉涼。
這天是周末，晚上天氣涼爽，小劉，小李，小高，小陳四個人，約好一起來擼串。他們是大學同學，學的是計算機，畢業后都到了深圳，目前都以寫程序為生，加入了程序員大軍。
程序員的聚餐節目是固定的，幾口大腰子下去，再加上幾杯啤酒下肚，幾個人不約而同的開始各種吐槽，從罵老板，罵上司，罵產品，罵設計，罵到最后，大家都懂。所謂的程序員的聊天以罵老板開始，以撕編程語言結束。
但是今天他們又開了一個新的話題，那就是代碼托管的工作流。
小劉率先發言，git 這貨 跟 svn 沒啥差別，我一貫還是按照以往的，寫完了就提交，我們三五個人的小團隊也都這樣，除了可以在本地不連服務器上也能提交代碼這點之外，跟 svn 沒啥差別，我們就只有一個主分支跟 svn 的主干是一樣的，大家都在這上面工作，團隊協作溝通非常高效。
小劉所講的工作流 -- Centralized Workflow
?
這套流程講究的就是快速，簡單，這對于大多數個人開發者和小型團隊來說是最好的選擇，往往是維護一個 App，個人博客，或者一個小型網站之類的。總結下來適用場景和基本特點是：
?
- 團隊人數少
- 開發不是很頻繁
- 團隊溝通方便
- 不需同時維護多個版本
繼續說回我們的故事。
小陳聽不下去了，說道：我們團隊都推行使用一個 git 的插件，叫做 git-flow， 所有成員，都按照這個軟件規定的標準流程進行協作，每次改動，我們都根據不同的情形，使用 git-flow 工具來新建相應的流程。大家都按照這個流程來，雖然繁瑣，但是我們三十幾個開發團隊共同維護幾個項目，從來都是運行平穩，從未出事，就你們那幾個人三天兩頭代碼庫被新手搞亂，居然還好意思叫團隊協作溝通高效？我看是搞笑吧，哈哈。
小劉氣的臉通紅，又沒啥話好說，只好忍了。
小陳所講的工作流 -- Git-flow Workflow
?
這套工作流講究的是平穩，有序，Git-flow 工作流在 Git 分支標簽等概念的基礎上，添加了一些 Feature，Release，Hotfix 等概念，用以精確描述代碼版本控制的一些流程，所有協作者在放棄一些個人效率的基礎上，統一開發流程，最終帶來的是整體的規模化的團隊的整體效率提升。其缺點是上手較難一點，需要一些基礎知識培訓，適用場景如下：
- 認為額外學習 Git-Flow 不是什么問題的
- 有專門的代碼倉庫管理員的
- 開發團隊相對固定，而且有一定規模
- 常常有并行開發需求
- 團隊對于 Release，Bug，Feature 這些概念有統一定義標準的
繼續說回我們的故事。
這時小李淡定的拿出一串羊肉，吃了一口，說道：我不知道你們說的是什么玩意，但是我作為一個自由職業者，維護著一個開源軟件，平時也給一些開源軟件貢獻些代碼，從來都是 Github 上 fork 完了，再提交 Pull Request 的，Pull Request 會被開源軟件的維護者評審，如果評審通過，就會合并到源項目。我作為一個開源軟件的維護者，既評審著別人給我的貢獻，也貢獻給別人評審，這是一個非常理想的生態循環，我不知道你們扯那些破玩意有啥用。
小李所講工作流 -- Fork Workflow
??
這套流程是專門為開源軟件量身打造的一套流程，最早的發明者是 Github，Github 是世界知名開源軟件倉庫。這個流程的最大特點就是，開發參與者可以不直接參與到項目中來，想貢獻代碼，只要 fork 目標項目后，就可以得到一個一模一樣的自有項目，做完修改后，提交 Pull Request 給原項目，如原項目的維護者采納了，即算貢獻完成。圖中看一看到，每個開發者（團隊）都擁有自己維護的一個項目，跟別人項目之間的聯系通過 Pull Request 形式解決。總結下來適用場景是：
- 常用于開源軟件
- 開發者有需要衍生出自己的衍生版的
- 開發者不固定，可能是任意一個網友
繼續說回我們的故事。
小高是個胖子，每次擼串最能吃，基本上聊天的時候都是偶爾插一句話。但是這時候，聽完這一頓撕，也忍不了了，用紙巾擦掉嘴上的辣椒說道：我們公司，跟你們選擇的都不同，我們公司使用基于 git-flow 簡化的一個模型來協同工作，不需要安裝什么 git 插件。版本庫有一個默認分支 master ，需要 release 的時候，就將默認分支打一個標簽，用作 release 。使用 Coding 提供的保護分支功能， master 指定若干管理員，其他人有任何修改都在默認分支 master 的基礎上新開分支，提交代碼，然后到 Coding 上向 master 提交合并請求，并可以指定若干團隊成員作為評審者，評審通過后就可以合并到 master 上了。也從來都運轉平穩，從未出事。
小高所講工作流 -- Feature Branch Workflow
??
這套流程屬于 Git-Flow 的簡化版，不再需要安裝額外 Git 插件，基于代碼托管平臺提供的一些基礎功能來實現，主要流程分 Feature 流程和 Bug 流程。這個流程是適用于大多數團隊人數在 5 人以上，有很多并行開發需求，切更新頻繁，開發任務重的協作團隊。其適用場景是：
- 開發團隊相對固定，而且有一定規模
- 常常有多個功能，多個問題并行開發
- 對代碼審查有較高要求
- 更注重團隊效率
小劉，這時才從小陳的話中緩過神來，對小陳說道，我們雖然是出過新手搞亂了代碼庫的問題，但是 git 都是有歷史的，并非不可恢復，關鍵是我們流程簡便，從來有任何問題都是快速響應，不像有些公司，修個 bug ，居然要等一周才能上線。
小李又說道，有啥好吵，都是沒啥卵用的玩意，你就按照 fork / pull request 來搞就行了。
你一句，我一句，七嘴八舌的，吵得不可開交。
。。。。。。
這四位的爭論越來越激烈，沒辦法，程序員的爭論都是撕破臉皮，面紅耳赤，直至燒烤店快要打烊了。最后驚動了燒烤店的老板娘。老板娘聽罷爭論，笑瞇瞇的走過來說：年輕人莫要激動，我雖然不知道講什么，但這世間萬物，都有適用范圍，沒有什么是絕對好的，也沒有什么是絕對壞的。就好比你們吃燒烤的辣椒，放在這烤肉上，味道就非常不錯，但是你見過哪家冷飲店放辣椒的么？
幾人聽完，瞬間覺得衛生阿姨就好比金庸小說掃地僧那般神奇，細思恐極，趕緊結了賬，匆匆離開了。
============ 這是分割線 ============
是啊，沒什么是絕對好的，也沒什么是絕對壞的，每樣東西都有適用范圍。
以上，適用場景并不定死，是靈活多變的，甚至于我們可以超出以上四種模型，取其精華，棄其糟粕，自己創造出新的模型來。總之，希望這篇文章能幫助你找到屬于符合自己的模型的 git 工作流。
來自：https://blog.coding.net/blog/git-workflow