使用git和github進行協同開發流程

做者：戴嘉華

轉載請註明出處，保留原文連接和做者信息

---

目錄

• 前言
• 倉庫（Repository）
  
  
  • 源倉庫
  • 開發者倉庫
• 分支（Branch）
  
  
  • 永久性分支
  • 暫時性分支
• 工做流（workflow）
• 總結
• 參考資料

前言

（本文假設各位已經對基本git的基本概念、操做有必定的理解，如無相關git知識，能夠參考Pro Git這本書進行相關的學習和練習）

不少項目開發都會採用git這一優秀的分佈式版本管理工具進行項目版本管理，使用github開源平臺做爲代碼倉庫託管平臺。因爲git的使用很是靈活，在實踐當中衍生了不少種不一樣的工做流程，不一樣的項目、不一樣的團隊會有不一樣的協做方式。

本文將介紹一種前人已經在各類大小項目中通過千錘百煉總結出來的一種比較成功的git工做流，這種工做流已經被成功用於許多團隊開發當中。掌握git，掌握這種工做流，對你們之後的學習、開發工做大有好處。

先上一張圖嚇你們一下：

上面一張圖展現了一種使用git進行項目協同開發的模式，接下來會進行詳細介紹。

倉庫（Repository）

在項目的開始到結束，咱們會有兩種倉庫。一種是源倉庫（origin），一種是開發者倉庫。上圖中的每一個矩形都表示一個倉庫，正中間的是咱們的源倉庫，而其餘圍繞着源倉庫的則是開發者倉庫。

源倉庫

在項目的開始，項目的發起者構建起一個項目的最原始的倉庫，咱們把它稱爲origin，例如咱們的PingHackers網站，origin就是這個PingHackers/blog了。源倉庫的有兩個做用：

1. 彙總參與該項目的各個開發者的代碼
2. 存放趨於穩定和可發佈的代碼

源倉庫應該是受保護的，開發者不該該直接對其進行開發工做。只有項目管理者（一般是項目發起人）能對其進行較高權限的操做。

開發者倉庫

上面說過，任何開發者都不會對源倉庫進行直接的操做，源倉庫創建之後，每一個開發者須要作的事情就是把源倉庫的「複製」一份，做爲本身平常開發的倉庫。這個複製，也就是github上面的fork。

每一個開發者所fork的倉庫是徹底獨立的，互不干擾，甚至與源倉庫都無關。每一個開發者倉庫至關於一個源倉庫實體的影像，開發者在這個影像中進行編碼，提交到本身的倉庫中，這樣就能夠輕易地實現團隊成員之間的並行開發工做。而開發工做完成之後，開發者能夠向源倉庫發送pull request，請求管理員把本身的代碼合併到源倉庫中，這樣就實現了分佈式開發工做，和最後的集中式的管理。

分支（Branch）

分支是git中很是重要的一個概念，也是git這一個工具中的大殺器，必殺技。在其餘集中式版本管理工具（SVN/CVS）把分支定位爲高級技巧，而在git中，分支操做則是每一個開發人員平常工做流。利用git的分支，能夠很是方便地進行開發和測試，若是使用git沒有讓你感到輕鬆和愉悅，那是由於你尚未學會使用分支。不把分支用出一點翔來，不要輕易跟別人說你用過git。

在文章開頭的那張圖中，每個矩形內部紛繁的枝蔓即是git的分支模型。能夠看出，每一個開發者的倉庫都有本身的分支路線，而這些分支路線會經過代碼彙總映射到源倉庫中去。

咱們爲git定下一種分支模型，在這種模型中，分支有兩類，五種

• 永久性分支
  
  
  • master branch：主分支
  • develop branch：開發分支
• 臨時性分支
  
  
  • feature branch：功能分支
  • release branch：預發佈分支
  • hotfix branch：bug修復分支

永久性分支

永久性分支是壽命無限的分支，存在於整個項目的開始、開發、迭代、終止過程當中。永久性分支只有兩個master和develop。

master：主分支從項目一開始便存在，它用於存放通過測試，已經徹底穩定代碼；在項目開發之後的任什麼時候刻當中，master存放的代碼應該是可做爲產品供用戶使用的代碼。因此，應該隨時保持master倉庫代碼的清潔和穩定，確保入庫以前是經過徹底測試和代碼reivew的。master分支是全部分支中最不活躍的，大概每月或每兩個月更新一次，每一次master更新的時候都應該用git打上tag，說明你的產品有新版本發佈了。

develop：開發分支，一開始從master分支中分離出來，用於開發者存放基本穩定代碼。以前說過，每一個開發者的倉庫至關於源倉庫的一個鏡像，每一個開發者本身的倉庫上也有master和develop。開發者把功能作好之後，是存放到本身的develop中，當測試完之後，能夠向管理者發起一個pull request，請求把本身倉庫的develop分支合併到源倉庫的develop中。

全部開發者開發好的功能會在源倉庫的develop分支中進行彙總，當develop中的代碼通過不斷的測試，已經逐漸趨於穩定了，接近產品目標了。這時候，咱們就能夠把develop分支合併到master分支中，發佈一個新版本。因此，一個產品不斷完善和發佈過程就正以下圖：

注意，任何人不該該向master直接進行無心義的合併、提交操做。正常狀況下，master只應該接受develop的合併，也就是說，master全部代碼更新應該源於合併develop的代碼。

暫時性分支

暫時性分支和永久性分支不一樣，暫時性分支在開發過程當中是必定會被刪除的。全部暫時性分支，通常源於develop，最終也必定會迴歸合併到develop。

feature：功能性分支，是用於開發項目的功能的分支，是開發者主要戰鬥陣地。開發者在本地倉庫從develop分支分出功能分支，在該分支上進行功能的開發，開發完成之後再合併到develop分支上，這時候功能性分支已經完成任務，能夠刪除。功能性分支的命名通常爲feature-*，*爲須要開發的功能的名稱。

舉一個例子，假設我是一名PingHackers網站的開發者，已經把源倉庫fork了，而且clone到了本地。如今要開發PingHackers網站的「討論」功能。我在本地倉庫中能夠這樣作：

step 1: 切換到develop分支

>>> git checkout develop

step 2: 分出一個功能性分支

>>> git checkout -b feature-discuss

step 3: 在功能性分支上進行開發工做，屢次commit，測試之後...

step 4: 把作好的功能合併到develop中

>>> git checkout develop

    # 回到develop分支

    >>> git merge --no-ff feature-discuss
    # 把作好的功能合併到develop中

    >>> git branch -d feature-discuss
    # 刪除功能性分支

    >>> git push origin develop
    # 把develop提交到本身的遠程倉庫中

這樣，就完成一次功能的開發和提交。

release：預發佈分支，當產品即將發佈的時候，要進行最後的調整和測試，這時候就能夠分出一個預發佈分支，進行最後的bug fix。測試徹底之後，發佈新版本，就能夠把預發佈分支刪除。預發佈分支通常命名爲release-*。

hotfix：修復bug分支，當產品已經發布了，忽然出現了重大的bug。這時候就要新建一個hotfix分支，繼續緊急的bug修復工做，當bug修復完之後，把該分支合併到master和develop之後，就能夠把該分支刪除。修復bug分支命名通常爲hotfix-*

release和hotfix分支離咱們還比較遙遠。。就不詳述，有興趣的同窗能夠參考本文最後的參考資料進行學習。

工做流（Workflow）

囉嗦講了這麼多，概念永遠是抽象的。對於新手來講，都喜歡一步一步的步驟傻瓜教程，接下來，咱們就一步一步來操做上面所說的工做流程，你們感覺一下：

Step 1：源倉庫的構建

這一步一般由項目發起人來操做，咱們這裏把管理員設爲PingHackers，假設PingHackers已經爲咱們創建起了一個源倉庫PingHackers/git-demo，而且已經初始化了兩個永久性分支master和develop，如圖：

Step 2：開發者fork源倉庫

源倉庫創建之後，每一個開發就能夠去複製一份源倉庫到本身的github帳號中，而後做爲本身開發所用的倉庫。假設我是一個項目中的開發者，我就到PingHackers/git-demo項目主頁上去fork：

fork完之後，我就能夠在我本身的倉庫列表中看到一個和源倉庫如出一轍的複製品。這時就應該感嘆，你之後要和它相依爲命了：

Step 3：把本身開發者倉庫clone到本地

這一步應該不用教，git clone

Step 4：構建功能分支進行開發

進入倉庫中，按照前面說所的構建功能分支的步驟，構建功能分支進行開發、合併，假設我如今要開發一個「討論」功能：

>>> git checkout develop
    # 切換到`develop`分支

    >>> git checkout -b feature-discuss
    # 分出一個功能性分支

    >> touch discuss.js
    # 僞裝discuss.js就是咱們要開發的功能

    >> git add .
    >> git commit -m 'finish discuss feature'
    # 提交更改

    >>> git checkout develop
    # 回到develop分支

    >>> git merge --no-ff feature-discuss
    # 把作好的功能合併到develop中

    >>> git branch -d feature-discuss
    # 刪除功能性分支

    >>> git push origin develop
    # 把develop提交到本身的遠程倉庫中

這時候，你上本身github的項目主頁中develop分支中看看，已經有discuss.js這個文件了：

Step 5：向管理員提交pull request

假設我完成了「討論」功能（固然，你還可能對本身的develop進行了屢次合併，完成了多個功能），通過測試之後，以爲沒問題，就能夠請求管理員把本身倉庫的develop分支合併到源倉庫的develop分支中，這就是傳說中的pull request。

點擊上圖的綠色按鈕，開發者就能夠就能夠靜靜地等待管理員對你的提交的評審了。

Step 6 管理員測試、合併

接下來就是管理員的操做了，做爲管理員的PingHackers登錄github，便看到了我對源倉庫發起的pull request。

這時候PingHackers須要作的事情就是：

1. 對個人代碼進行review。github提供很是強大的代碼review功能：
   

2. 在他的本地測試新建一個測試分支，測試個人代碼：

   >> git checkout develop
   # 進入他本地的develop分支
   
   >> git checkout -b livoras-develop
   # 從develop分支中分出一個叫livoras-develop的測試分支測試個人代碼
   
   >> git pull https://github.com/livoras/git-demo.git develop
   # 把個人代碼pull到測試分支中，進行測試

3. 判斷是否贊成合併到源倉庫的develop中，若是通過測試沒問題，能夠把個人代碼合併到源倉庫的develop中：

   >> git checkout develop
   >> git merge --no-ff livoras-develop
   >> git push origin develop

注意，PingHakers一直在操做的倉庫是源倉庫。因此咱們通過上面一系列操做之後，就能夠在源倉庫主頁中看到：

通過展轉曲折的路程，咱們的discuss.js終於從個人開發倉庫的功能分支到達了源倉庫的develop分支中。以上，就是一個git & github協同工做流的基本步驟。

總結

git這一個工具博大精深，很難想象居然有使用如此噁心而又如此靈活和優雅的工具存在；此又爲一神器，你們仍是多動手，多查資料，讓git成爲本身的一項基本技能，幫助本身處理各類項目團隊協同工做的問題，成爲一個高效的開發者、優秀的項目的管理者。送你們一張神圖，好好領悟：

最後給出一些參考資料，供參考學習。

參考資料

• A Successful Git Branching Model
• Understanding the Git Workflow
• Github flow
• Pro Git
• Git分支管理策略