深刻理解學習Git工做流

文／ixirong（簡書做者）
原文連接：http://www.jianshu.com/p/91acec85c3a4
著做權歸做者所有。轉載請聯繫做者得到受權，並標註「簡書做者」。

• 咱們以使用SVN的工做流來使用git有什麼不妥？
• git 方便的branch在哪裏，團隊多人怎樣協做？衝突了怎麼辦？怎樣進行公佈控制？
• 經典的master-公佈、develop-主開發、hotfix-只是修復怎樣避免代碼不通過驗證上線？
• 怎樣在github上面與他人一塊兒協做，star-fork-pull request是怎樣的流程？

我我的很是感激這篇文章，因此進行了整理，但願能幫到不少其它的人。

整篇文章由 xirong 整理自 oldratlee 的github。方便統一的學習回想。在此感謝如下兩位的貢獻。

原文連接：Git Workflows and Tutorials
中文簡體：由 oldratlee 翻譯在 github 上 git-workflows-and-tutorials

---

1、譯序

工做流事實上不是一個0基礎主題，背後的本質問題事實上是有效的項目流程管理和高效的開發協同約定，不只是Git或SVN等VCS或SCM工具的使用。

這篇指南以你們在SVN中已經廣爲熟悉使用的集中式工做流做爲起點，按部就班地演進到其餘高效的分佈式工做流。還介紹了怎樣配合使用便利的Pull Request功能，體系地解說了各類工做流的應用。

行文中實踐原則和操做演示樣例並重。對於Git的資深玩家可以梳理思考提高，而新接觸的同窗。也可以跟着step-by-step操做來操練學習並在實際工做中上手使用。

關於Git工做流主題，網上體系的中文資料很少。主要是零散的操做說明。但願這篇文章能讓你更深刻理解並在工做中靈活有效地使用起來。

PS：

文中Pull Request的介紹用的是Bitbucket代碼託管服務，由於和GitHub基本同樣，假設你用的是GitHub（我本身也主要使用GitHub託管代碼），不影響理解和操做。

PPS：

本指南按部就班地解說工做流。假設Git用的很少，可以從前面的講的工做流開始操練。操做過程去感覺指南的解說：解決什麼問題、怎樣解決這個問題，這樣理解就深了，也方便活用。

Gitflow工做流是經典模型，體現了工做流的經驗和精髓。隨着項目過程複雜化。會感覺到這個工做流中深思熟慮和威力！

Forking工做流是協做的（GitHub風格）可以先看看Github的Help：Fork A Repo和Using pull requests 。照着操做，給一個Github項目貢獻你的提交，有操做經驗再看指南easy意會。指南中給了本身實現Fork的方法：Fork就是服務端的克隆。在指南的操練中使用代碼託管服務（如GitHub、Bitbucket），可以點一下button就讓開發人員完畢倉庫的fork操做。

:see_no_evil: 本身理解粗淺。翻譯中不足和不正確之處，歡迎建議（提交Issue）和指正（Fork後提交代碼）！

2、Git工做流指南

:point_right: 工做流有各式各樣的使用方法。但也正所以使得在實際工做中怎樣上手使用變得很是頭大。這篇指南經過總覽公司團隊中最常用的幾種Git工做流讓你們可以上手使用。

在閱讀的過程當中請記住，本文中的幾種工做流是做爲方案指導而不是條例規定。在展現了各類工做流可能的使用方法後，你可以從不一樣的工做流中挑選或揉合出一個知足你本身需求的工做流。

Git Workflows

2.1 集中式工做流

假設你的開發團隊成員已經很是熟悉Subversion，集中式工做流讓你無需去適應一個全新流程就可以體驗Git帶來的收益。

這個工做流也可以做爲向更Git風格工做流遷移的友好過渡。

Git Workflows: SVN-style

轉到分佈式版本號控制系統看起來像個使人生畏的任務，但不改變已用的工做流你也可以用上Git帶來的收益。團隊可以用和Subversion全然不變的方式來開發項目。

但使用Git增強開發的工做流，Git有相比SVN的幾個優點。

首先，每個開發可以有屬於本身的整個project的本地拷貝。隔離的環境讓各個開發人員的工做和項目的其它部分改動獨立開來 ——
即自由地提交到本身的本地倉庫，先全然忽略上游的開發，直到方便的時候再把改動反饋上去。

其次，Git提供了強壯的分支和合並模型。不像SVN，Git的分支設計成可以作爲一種用來在倉庫之間集成代碼和分享改動的『失敗安全』的機制。

2.1.1 工做方式

像Subversion同樣。集中式工做流以中央倉庫做爲項目所有改動的單點實體。

相比SVN缺省的開發分支trunk，Git叫作master。所有改動提交到這個分支上。

本工做流僅僅用到master這一個分支。

開發人員開始先克隆中央倉庫。在本身的項目拷貝中像SVN同樣的編輯文件和提交改動；但改動是存在本地的。和中央倉庫是全然隔離的。開發人員可以把和上游的同步延後到一個方便時間點。

要公佈改動到正式項目中。開發人員要把本地master分支的改動『推』到中央倉庫中。這至關於svn commit操做。但push操做會把所有還不在中央倉庫的本地提交都推上去。

git-workflow-svn-push-local

2.1.2 衝突解決

中央倉庫表明了正式項目，因此提交歷史應該被尊重且是穩定不變的。假設開發人員本地的提交歷史和中央倉庫有分歧，Git會拒絕push提交不然會覆蓋已經在中央庫的正式提交。

git-workflow-svn-managingconflicts

在開發人員提交本身功能改動到中央庫前，需要先fetch在中央庫的新增提交。rebase本身提交到中央庫提交歷史之上。
這樣作的意思是在說，『我要把本身的改動加到別人已經完畢的改動上。』終於的結果是一個完美的線性歷史，就像曾經的SVN的工做流中同樣。

假設本地改動和上游提交有衝突，Git會暫停rebase過程。給你手動解決衝突的機會。

Git解決合併衝突，用和生成提交同樣的git status和git add命令，很是一致方便。另外一點，假設解決衝突時遇到麻煩，Git可以很是easy停止整個rebase操做，重來一次（或者讓別人來幫助解決）。

2.1.3 演示樣例

讓咱們一塊兒逐步分解來看看一個常見的小團隊怎樣用這個工做流來協做的。有兩個開發人員小明和小紅，看他們是怎樣開發本身的功能並提交到中央倉庫上的。

有人先初始化好中央倉庫

第一步。有人在server上建立好中央倉庫。假設是新項目，你可以初始化一個空倉庫；不然你要導入已有的Git或SVN倉庫。

中央倉庫應該是個裸倉庫（bare repository）。即沒有工做文件夾（working directory）的倉庫。

可以用如下的命令建立：

ssh user@host
git init --bare /path/to/repo.git

確保寫上有效的user（SSH的username），host（server的域名或IP地址），/path/to/repo.git（你想存放倉庫的位置）。
注意，爲了表示是一個裸倉庫，依照約定加上.git擴展名到倉庫名上。

所有人克隆中央倉庫

下一步，各個開發人員建立整個項目的本地拷貝。經過git clone命令完畢：

git clone ssh://user@host/path/to/repo.git

基於你興許會持續和克隆的倉庫作交互的若是。克隆倉庫時Git會本身主動加入遠程別名origin指回『父』倉庫。

小明開發功能

在小明的本地倉庫中，他使用標準的Git過程開發功能：編輯、暫存（Stage）和提交。
假設你不熟悉暫存區（Staging Area）。這裏說明一下：暫存區的用來準備一個提交，但可以不用把工做文件夾中所有的改動內容都包括進來。
這樣你可以建立一個高度聚焦的提交，雖然你本地改動很是多內容。

git status # 查看本地倉庫的改動狀態
git add # 暫存文件
git commit # 提交文件

請記住，因爲這些命令生成的是本地提交。小明可以按本身需求重複操做屢次。而不用操心中央倉庫上有了什麼操做。
對需要多個更簡單更原子分塊的大功能，這個作法是很是實用的。

小紅開發功能

與此同一時候。小紅在本身的本地倉庫中用一樣的編輯、暫存和提交過程開發功能。

和小明同樣。她也不關心中央倉庫有沒有新提交；
固然更不關心小明在他的本地倉庫中的操做。因爲所有本地倉庫都是私有的。

小明公佈功能

一旦小明完畢了他的功能開發，會公佈他的本地提交到中央倉庫中，這樣其餘團隊成員可以看到他的改動。

他可以用如下的git push命令：

git push origin master

注意，origin是在小明克隆倉庫時Git建立的遠程中央倉庫別名。master參數告訴Git推送的分支。

由於中央倉庫自從小明克隆以來尚未被更新過。因此push操做不會有衝突。成功完畢。

小紅試着公佈功能

一塊兒來看看在小明公佈改動後，小紅push改動會怎麼樣？她使用全然同樣的push命令：

git push origin master

但她的本地歷史已經和中央倉庫有分岐了。Git拒絕操做並給出如下很是長的出錯消息：

error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

這避免了小紅覆寫正式的提交。

她要先pull小明的更新到她的本地倉庫合併上她的本地改動後。再重試。

小紅在小明的提交之上rebase

小紅用git pull合併上游的改動到本身的倉庫中。
這條命令相似svn update——拉取所有上游提交命令到小紅的本地倉庫。並嘗試和她的本地改動合併：

git pull --rebase origin master

--rebase選項告訴Git把小紅的提交移到同步了中央倉庫改動後的master分支的頂部，例如如下圖所看到的：

假設你忘加了這個選項。pull操做仍然可以完畢，但每次pull操做要同步中央倉庫中別人改動時。提交歷史會以一個多餘的『合併提交』結尾。

對於集中式工做流。最好是使用rebase而不是生成一個合併提交。

小紅解決合併衝突

rebase操做過程是把本地提交一次一個地遷移到更新了的中央倉庫master分支之上。

這意味着可能要解決在遷移某個提交時出現的合併衝突。而不是解決包括了所有提交的大型合併時所出現的衝突。
這種方式讓你儘量保持每個提交的聚焦和項目歷史的整潔。反過來。簡化了哪裏引入Bug的分析，假設有必要，回滾改動也可以作到對項目影響最小。

假設小紅和小明的功能是相關的。不大可能在rebase過程當中有衝突。假設有，Git在合併有衝突的提交處暫停rebase過程。輸出如下的信息並帶上相關的指令：

CONFLICT (content): Merge conflict in <some-file>

Git很是讚的一點是，不論什麼人可以解決他本身的衝突。

在這個樣例中。小紅可以簡單的執行git status命令來查看哪裏有問題。
衝突文件列在Unmerged paths（未合併路徑）一節中：

# Unmerged paths:
# (use "git reset HEAD <some-file>..." to unstage) # (use "git add/rm <some-file>..." as appropriate to mark resolution) # # both modified: <some-file>

接着小紅編輯這些文件。改動完畢後。用老套路暫存這些文件，並讓git rebase完畢剩下的事：

git add <some-file> 
git rebase --continue

要作的就這些了。

Git會繼續一個一個地合併後面的提交，如其餘的提交有衝突就反覆這個過程。

假設你碰到了衝突。但發現搞不定。不要驚慌。僅僅要運行如下這條命令。就可以回到你運行git pull --rebase命令前的樣子：

git rebase --abort

小紅成功公佈功能

小紅完畢和中央倉庫的同步後。就能成功公佈她的改動了：

git push origin master

如你所見。僅使用幾個Git命令咱們就可以模擬出傳統Subversion開發環境。對於要從SVN遷移過來的團隊來講這太好了，但沒有發揮出Git分佈式本質的優點。

假設你的團隊適應了集中式工做流。但想要更流暢的協做效果。絕對值得探索一下 功能分支工做流 的收益。

經過爲一個功能分配一個專門的分支，能夠作到一個新增功能集成到正式項目以前對新功能進行深刻討論。

---

2.2 功能分支工做流

功能分支工做流以集中式工做流爲基礎，不一樣的是爲各個新功能分配一個專門的分支來開發。

這樣可以在把新功能集成到正式項眼下，用Pull Requests的方式討論變動。

Git Workflows: Feature Branch

一旦你玩轉了集中式工做流，在開發過程當中可以很是easy地加上功能分支，用來鼓舞開發人員之間協做和簡化交流。

功能分支工做流背後的核心思路是所有的功能開發應該在一個專門的分支。而不是在master分支上。
這個隔離可以方便多個開發人員在各自的功能上開發而不會弄亂主幹代碼。

另外，也保證了master分支的代碼必定不會是有問題的，極大有利於集成環境。

功能開發隔離也讓pull requests工做流成功可能。
pull requests工做流能爲每個分支發起一個討論，在分支合入正式項目以前，給其餘開發人員有表示贊同的機會。
另外，假設你在功能開發中有問題卡住了，可以開一個pull requests來向同窗們徵求建議。
這些作法的重點就是，pull requests讓團隊成員之間互相評論工做變成很方便！

2.2.1 工做方式

功能分支工做流仍然用中央倉庫，並且master分支仍是表明了正式項目的歷史。

但不是直接提交本地歷史到各自的本地master分支，開發人員每次在開始新功能前先建立一個新分支。
功能分支應該有個有描寫敘述性的名字，比方animated-menu-items或issue-#1061。這樣可以讓分支有個清楚且高聚焦的用途。

在master分支和功能分支之間，Git是沒有技術上的差異。因此開發人員可以用和集中式工做流中全然同樣的方式編輯、暫存和提交改動到功能分支上。

另外，功能分支也可以（且應該）push到中央倉庫中。這樣不改動正式代碼就可以和其餘開發人員分享提交的功能。
由於master僅有的一個『特殊』分支，在中央倉庫上存多個功能分支不會有不論什麼問題。固然。這樣作也可以很是方便地備份各自的本地提交。

2.2.2 Pull Requests

功能分支除了可以隔離功能的開發，也使得經過Pull Requests討論變動成爲可能。

一旦某個開發完畢一個功能，不是立刻合併到master。而是push到中央倉庫的功能分支上併發起一個Pull Request請求去合併改動到master。
在改動成爲主幹代碼前，這讓其餘的開發人員有機會先去Review變動。

Code Review是Pull Requests的一個重要的收益，但Pull Requests目的是討論代碼一個通用方式。
你可以把Pull Requests做爲專門給某個分支的討論。這意味着可以在更早的開發過程當中就可以進行Code Review。
比方。一個開發人員開發功能需要幫助時，要作的就是發起一個Pull Request，相關的人就會本身主動收到通知。在相關的提交旁邊能看到需要幫助解決的問題。

一旦Pull Request被接受了。公佈功能要作的就和集中式工做流就很是像了。
首先。肯定本地的master分支和上游的master分支是同步的。而後合併功能分支到本地master分支並push已經更新的本地master分支到中央倉庫。

倉庫管理的產品解決方式像Bitbucket或Stash，可以良好地支持Pull Requests。

可以看看Stash的Pull Requests文檔。

2.2.3 演示樣例

如下的演示樣例演示了怎樣把Pull Requests做爲Code Review的方式，但注意Pull Requests可以用於很是多其餘的目的。

小紅開始開發一個新功能

在開始開發功能前。小紅需要一個獨立的分支。使用如下的命令新建一個分支：

git checkout -b marys-feature master

這個命令檢出一個基於master名爲marys-feature的分支，Git的-b選項表示假設分支還不存在則新建分支。
這個新分支上，小紅按老套路編輯、暫存和提交改動，按需要提交以實現功能：

git status
git add <some-file>
git commit

小紅要去吃個午餐

早上小紅爲新功能加入一些提交。
去吃午餐前，push功能分支到中央倉庫是很是好的作法，這樣可以方便地備份。假設和其餘開發協做，也讓他們可以看到小紅的提交。

git push -u origin marys-feature

這條命令push marys-feature分支到中央倉庫（origin），-u選項設置本地分支去跟蹤遠程相應的分支。

設置好跟蹤的分支後，小紅就可以使用git push命令省去指定推送分支的參數。

小紅完畢功能開發

小紅吃完午餐回來，完畢整個功能的開發。在合併到master以前，
她發起一個Pull Request讓團隊的其餘人知道功能已經完畢。

但首先，她要確認中央倉庫中已經有她近期的提交：

git push

而後，在她的Git GUIclient中發起Pull Request，請求合併marys-feature到master，團隊成員會本身主動收到通知。
Pull Request很是酷的是可以在相關的提交旁邊顯示評註，因此你可以很是對某個變動集提問。

小黑收到Pull Request

小黑收到了Pull Request後會查看marys-feature的改動。決定在合併到正式項眼下是否要作些改動。且經過Pull Request和小紅來回地討論。

小紅再作改動

要再作改動。小紅用和功能第一個迭代全然同樣的過程。編輯、暫存、提交併push更新到中央倉庫。小紅這些活動都會顯示在Pull Request上。小黑可以斷續作評註。

假設小黑有需要，也可以把marys-feature分支拉到本地，本身來改動，他加的提交也會同樣顯示在Pull Request上。

小紅公佈她的功能

一旦小黑可以的接受Pull Request，就可以合併功能到穩定項目代碼中（可以由小黑或是小紅來作這個操做）：

git checkout master
git pull
git pull origin marys-feature
git push

無論誰來作合併。首先要檢出master分支並確認是它是最新的。而後運行git pull origin marys-feature合併marys-feature分支到和已經和遠程一致的本地master分支。

你可以使用簡單git merge marys-feature命令，但前面的命令可以保證老是最新的新功能分支。
最後更新的master分支要又一次push回到origin。

這個過程常常會生成一個合併提交。有些開發人員喜歡有合併提交，因爲它像一個新功能和原來代碼基線的連通符。

但假設你偏心線性的提交歷史，可以在運行合併時rebase新功能到master分支的頂部，這樣生成一個快進（fast-forward）的合併。

一些GUIclient可以僅僅要點一下『接受』button運行好上面的命令來本身主動化Pull Request接受過程。

假設你的不能這樣。至少在功能合併到master分支後能本身主動關閉Pull Request。

與此同一時候，小明在作和小紅同樣的事

當小紅和小黑在marys-feature上工做並討論她的Pull Request的時候。小明在本身的功能分支上作全然同樣的事。

經過隔離功能到獨立的分支上，每個人都可以自主的工做，固然必要的時候在開發人員之間分享變動仍是比較繁瑣的。

到了這裏，希望你發現了功能分支可以很是直接地在 集中式工做流 的僅有的master分支上完畢多功能的開發。

另外。功能分支還使用了Pull Request，使得可以在你的版本號控制GUIclient中討論某個提交。

功能分支工做流是開發項目異常靈活的方式。問題是，有時候太靈活了。對於大型團隊，常常需要給不一樣分支分配一個更詳細的角色。
Gitflow工做流是管理功能開發、公佈準備和維護的常用模式。

---

2.3 Gitflow工做流

Gitflow工做流經過爲功能開發、公佈準備和維護分配獨立的分支，讓公佈迭代過程更流暢。

嚴格的分支模型也爲大型項目提供了一些很必要的結構。

Git Workflows: Gitflow Cycle

這節介紹的Gitflow工做流借鑑自在nvie的Vincent Driessen。

Gitflow工做流定義了一個環繞項目公佈的嚴格分支模型。

儘管比功能分支工做流複雜幾分，但提供了用於一個健壯的用於管理大型項目的框架。

Gitflow工做流沒實用超出功能分支工做流的概念和命令，而是爲不一樣的分支分配一個很是明白的角色，並定義分支之間怎樣和何時進行交互。
除了使用功能分支，在作準備、維護和記錄公佈也使用各自的分支。
固然你可以用上功能分支工做流所有的優勢：Pull Requests、隔離實驗性開發和更高效的協做。

2.3.1 工做方式

Gitflow工做流仍然用中央倉庫做爲所有開發人員的交互中心。

和其餘的工做流同樣。開發人員在本地工做並push分支到要中央倉庫中。

2.3.2 歷史分支

相對使用僅有的一個master分支，Gitflow工做流使用2個分支來記錄項目的歷史。master分支存儲了正式公佈的歷史，而develop分支做爲功能的集成分支。
這樣也方便master分支上的所有提交分配一個版本。

剩下要說明的問題環繞着這2個分支的差異展開。

2.3.3 功能分支

每個新功能位於一個本身的分支，這樣可以push到中央倉庫以備份和協做。
但功能分支不是從master分支上拉出新分支，而是使用develop分支做爲父分支。

當新功能完畢時。合併回develop分支。
新功能提交應該從不直接與master分支交互。

注意。從各類含義和目的上來看，功能分支加上develop分支就是功能分支工做流的使用方法。但Gitflow工做流沒有在這裏止步。

2.3.4 公佈分支

一旦develop分支上有了作一次公佈（或者說快到了既定的公佈日）的足夠功能。就從develop分支上fork一個公佈分支。
新建的分支用於開始公佈循環，因此從這個時間點開始以後新的功能不能再加到這個分支上——
這個分支僅僅應該作Bug修復、文檔生成和其餘面向公佈任務。
一旦對外公佈的工做都完畢了，公佈分支合併到master分支並分配一個版本打好Tag。

另外，這些重新建公佈分支以來的作的改動要合併回develop分支。

使用一個用於公佈準備的專門分支，使得一個團隊可以在無缺當前的公佈版本號的同一時候，還有一個團隊可以繼續開發下個版本號的功能。
這也打造定義良好的開發階段（比方，可以很是輕鬆地說，『這周咱們要作準備公佈版本號4.0』，並且在倉庫的文件夾結構中可以實際看到）。

常用的分支約定：

用於新建公佈分支的分支: develop
用於合併的分支: master
分支命名: release-* 或 release/*

2.3.5 維護分支

維護分支或說是熱修復（hotfix）分支用於生成高速給產品公佈版本號（production releases）打補丁，這是惟一可以直接從master分支fork出來的分支。
修復完畢，改動應該當即合併回master分支和develop分支（當前的公佈分支），master分支應該用新的版本打好Tag。

爲Bug修復使用專門分支，讓團隊可以處理掉問題而不用打斷其餘工做或是等待下一個公佈循環。
你可以把維護分支想成是一個直接在master分支上處理的暫時公佈。

2.3.6 演示樣例

如下的演示樣例演示本工做流怎樣用於管理單個公佈循環。若是你已經建立了一箇中央倉庫。

建立開發分支

第一步爲master分支配套一個develop分支。

簡單來作可以本地建立一個空的develop分支，push到server上：

git branch develop
git push -u origin develop

之後這個分支將會包括了項目的全部歷史，而master分支將僅僅包括了部分歷史。其餘開發人員這時應該克隆中央倉庫，建好develop分支的跟蹤分支：

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

現在每個開發都有了這些歷史分支的本地拷貝。

小紅和小明開始開發新功能

這個演示樣例中。小紅和小明開始各自的功能開發。他們需要爲各自的功能建立對應的分支。新分支不是基於master分支。而是應該基於develop分支：

git checkout -b some-feature develop

他們用老套路加入提交到各自功能分支上：編輯、暫存、提交：

git status
git add <some-file>
git commit

小紅完畢功能開發

加入了提交後，小紅認爲她的功能OK了。假設團隊使用Pull Requests，這時候可以發起一個用於合併到develop分支。
不然她可以直接合併到她本地的develop分支後push到中央倉庫：

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一條命令在合併功能前確保develop分支是最新的。注意。功能決不該該直接合併到master分支。

衝突解決方法和集中式工做流同樣。

小紅開始準備公佈

這個時候小明正在實現他的功能，小紅開始準備她的第一個項目正式公佈。
像功能開發同樣。她用一個新的分支來作公佈準備。這一步也肯定了公佈的版本：

git checkout -b release-0.1 develop

這個分支是清理公佈、運行所有測試、更新文檔和其餘爲下個公佈作準備操做的地方。像是一個專門用於改善公佈的功能分支。

僅僅要小紅建立這個分支並push到中央倉庫，這個公佈就是功能凍結的。

不論什麼不在develop分支中的新功能都推到下個公佈循環中。

小紅完畢公佈

一旦準備好了對外公佈，小紅合併改動到master分支和develop分支上。刪除公佈分支。合併回develop分支很是重要，因爲在公佈分支中已經提交的更新需要在後面的新功能中也要是可用的。
另外，假設小紅的團隊要求Code Review。這是一個發起Pull Request的理想時機。

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

公佈分支是做爲功能開發（develop分支）和對外公佈（master分支）間的緩衝。僅僅要有合併到master分支，就應該打好Tag以方便跟蹤。

git tag -a 0.1 -m "Initial public release" master
git push --tags

Git有提供各類勾子（hook），即倉庫有事件發生時觸發運行的腳本。
可以配置一個勾子。在你push中央倉庫的master分支時，本身主動構建好對外公佈。

終於用戶發現Bug

對外公佈後，小紅回去和小明一塊兒作下個公佈的新功能開發，直到有終於用戶開了一個Ticket抱怨當前版本號的一個Bug。

爲了處理Bug，小紅（或小明）從master分支上拉出了一個維護分支，提交改動以解決這個問題，而後直接合並回master分支：

git checkout -b issue-#001 master
# Fix the bug
git checkout master
git merge issue-#001
git push

就像公佈分支，維護分支中新加這些重要改動需要包括到develop分支中，因此小紅要運行一個合併操做。而後就可以安全地刪除這個分支了：

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001

到了這裏。希望你對集中式工做流、功能分支工做流和Gitflow工做流已經感受很是溫馨了。
你應該也堅固的掌握了本地倉庫的潛能，push/pull模式和Git健壯的分支和合並模型。

記住，這裏演示的工做流僅僅是可能使用方法的樣例，而不是在實際工做中使用Git不可違逆的條例。
因此不要畏懼按本身需要對工做流的使用方法作取捨。不變的目標就是讓Git爲你所用。

---

2.4 Forking工做流

Forking工做流是分佈式工做流，充分利用了Git在分支和克隆上的優點。可以安全可靠地管理大團隊的開發人員（developer），並能接受不信任貢獻者（contributor）的提交。

Forking工做流和前面討論的幾種工做流有根本的不一樣，這樣的工做流不是使用單個服務端倉庫做爲『中央』代碼基線。而讓各個開發人員都有一個服務端倉庫。這意味着各個代碼貢獻者有2個Git倉庫而不是1個：一個本地私有的，還有一個服務端公開的。

Forking工做流的一個主要優點是，貢獻的代碼可以被集成。而不需要所有人都能push代碼到僅有的中央倉庫中。
開發人員push到本身的服務端倉庫。而僅僅有項目維護者才幹push到正式倉庫。
這樣項目維護者可以接受不論什麼開發人員的提交，但無需給他正式代碼庫的寫權限。

效果就是一個分佈式的工做流，能爲大型、自發性的團隊（包含了不受信的第三方）提供靈活的方式來安全的協做。

也讓這個工做流成爲開源項目的理想工做流。

2.4.1 工做方式

和其餘的Git工做流同樣。Forking工做流要先有一個公開的正式倉庫存儲在server上。
但一個新的開發人員想要在項目上工做時，不是直接從正式倉庫克隆，而是fork正式項目在server上建立一個拷貝。

這個倉庫拷貝做爲他我的公開倉庫 ——
其餘開發人員不一樣意push到這個倉庫，但可以pull到改動（後面咱們很是快就會看這點很是重要）。
在建立了本身服務端拷貝以後，和以前的工做流同樣，開發人員運行git clone命令克隆倉庫到本地機器上。做爲私有的開發環境。

要提交本地改動時，push提交到本身公開倉庫中 —— 而不是正式倉庫中。
而後，給正式倉庫發起一個pull request。讓項目維護者知道有更新已經準備好可以集成了。
對於貢獻的代碼，pull request也可以很是方便地做爲一個討論的地方。

爲了集成功能到正式代碼庫，維護者pull貢獻者的變動到本身的本地倉庫中，檢查變動以確保不會讓項目出錯，
合併變動到本身本地的master分支，
而後pushmaster分支到server的正式倉庫中。
到此。貢獻的提交成爲了項目的一部分。其餘的開發人員應該運行pull操做與正式倉庫同步本身本地倉庫。

2.4.2 正式倉庫

在Forking工做流中，『官方』倉庫的叫法僅僅是一個約定，理解這點很是重要。
從技術上來看，各個開發人員倉庫和正式倉庫在Git看來沒有不論什麼差異。
其實，讓正式倉庫之因此正式的惟一緣由是它是項目維護者的公開倉庫。

2.4.3 Forking工做流的分支使用方式

所有的我的公開倉庫實際上僅僅是爲了方便和其餘的開發人員共享分支。
各個開發人員應該用分支隔離各個功能，就像在功能分支工做流和Gitflow工做流同樣。
惟一的差異是這些分支被共享了。在Forking工做流中這些分支會被pull到還有一個開發人員的本地倉庫中，而在功能分支工做流和Gitflow工做流中是直接被push到正式倉庫中。

2.4.4 演示樣例

項目維護者初始化正式倉庫

和不論什麼使用Git項目同樣，第一步是建立在server上一個正式倉庫，讓所有團隊成員都可以訪問到。
一般這個倉庫也會做爲項目維護者的公開倉庫。

公開倉庫應該是裸倉庫。不管是否是正式代碼庫。
因此項目維護者會執行像如下的命令來搭建正式倉庫：

ssh user@host
git init --bare /path/to/repo.git

Bitbucket和Stash提供了一個方便的GUIclient以完畢上面命令行作的事。

這個搭建中央倉庫的過程和前面提到的工做流全然同樣。
假設有現存的代碼庫，維護者也要push到這個倉庫中。

開發人員fork正式倉庫

其餘所有的開發需要fork正式倉庫。
可以用git clone命令用SSH協議連通到server。
拷貝倉庫到server還有一個位置 —— 是的。fork操做基本上就僅僅是一個服務端的克隆。
Bitbucket和Stash上可以點一下button就讓開發人員完畢倉庫的fork操做。

這一步完畢後，每個開發都在服務端有一個本身的倉庫。和正式倉庫同樣。這些倉庫應該是裸倉庫。

開發人員克隆本身fork出來的倉庫

下一步。各個開發人員要克隆本身的公開倉庫，用熟悉的git clone命令。

在這個演示樣例中。假定用Bitbucket託管了倉庫。記住，假設這種話各個開發人員需要有各自的Bitbucket帳號，
使用如下命令克隆服務端本身的倉庫：

git clone https://user@bitbucket.org/user/repo.git

相比前面介紹的工做流僅僅用了一個origin遠程別名指向中央倉庫。Forking工做流需要2個遠程別名 ——
一個指向正式倉庫，還有一個指向開發人員本身的服務端倉庫。別名的名字可以隨意命名，常見的約定是使用origin做爲遠程克隆的倉庫的別名
（這個別名會在執行git clone本身主動建立）。upstream（上游）做爲正式倉庫的別名。

git remote add upstream https://bitbucket.org/maintainer/repo

需要本身用上面的命令建立upstream別名。這樣可以簡單地保持本地倉庫和正式倉庫的同步更新。
注意，假設上游倉庫需要認證（比方不是開源的）。你需要提供用戶：

git remote add upstream https://user@bitbucket.org/maintainer/repo.git

這時在克隆和pull正式倉庫時。需要提供用戶的password。

開發人員開發本身的功能

在剛克隆的本地倉庫中，開發人員可以像其餘工做流同樣的編輯代碼、提交改動和新建分支：

git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"

所有的改動都是私有的直到push到本身公開倉庫中。假設正式項目已經往前走了，可以用git pull命令得到新的提交：

git pull upstream master

由於開發人員應該都在專門的功能分支上工做。pull操做結果會都是快進合併。

開發人員公佈本身的功能

一旦開發人員準備好了分享新功能，需要作二件事。

首先，經過push他的貢獻代碼到本身的公開倉庫中。讓其餘的開發人員都可以訪問到。

他的origin遠程別名應該已經有了，因此要作的就是：

git push origin feature-branch

這裏和以前的工做流的差別是，origin遠程別名指向開發人員本身的服務端倉庫，而不是正式倉庫。

第二件事，開發人員要通知項目維護者。想要合併他的新功能到正式庫中。
Bitbucket和Stash提供了Pull Requestbutton，彈出表單讓你指定哪一個分支要合併到正式倉庫。

通常你會想集成你的功能分支到上游遠程倉庫的master分支中。

項目維護者集成開發人員的功能

當項目維護者收到pull request，他要作的是決定是否集成它到正式代碼庫中。有二種方式來作：

1. 直接在pull request中查看代碼
2. pull代碼到他本身的本地倉庫。再手動合併

第一種作法更簡單。維護者可以在GUI中查看變動的差別。作評註和運行合併。
但假設出現了合併衝突。需要另一種作法來解決。

這樣的狀況下，維護者需要從開發人員的服務端倉庫中fetch功能分支，
合併到他本地的master分支，解決衝突：

git fetch https://bitbucket.org/user/repo feature-branch
# 查看變動
git checkout master
git merge FETCH_HEAD

變動集成到本地的master分支後。維護者要push變動到server上的正式倉庫，這樣其餘的開發人員都能訪問到：

git push origin master

注意，維護者的origin是指向他本身公開倉庫的。便是項目的正式代碼庫。到此，開發人員的貢獻全然集成到了項目中。

開發人員和正式倉庫作同步

由於正式代碼庫往前走了，其餘的開發需要和正式倉庫作同步：

git pull upstream master

假設你以前是使用SVN，Forking工做流可能看起來像是一個激進的範式切換（paradigm shift）。

但不要懼怕。這個工做流實際上就是在功能分支工做流之上引入還有一個抽象層。
不是直接經過單箇中央倉庫來分享分支，而是把貢獻代碼公佈到開發人員本身的服務端倉庫中。

演示樣例中解釋了。一個貢獻怎樣從一個開發人員流到正式的master分支中，但相同的方法可以把貢獻集成到任一個倉庫中。
比方，假設團隊的幾我的協做實現一個功能，可以在開發之間用一樣的方法分享變動。全然不涉及正式倉庫。

這使得Forking工做流對於鬆散組織的團隊來講是個很強大的工具。任一開發人員可以方便地和還有一開發人員分享變動，不論什麼分支都能有效地合併到正式代碼庫中。

---

2.5 Pull Requests

Pull requests是Bitbucket提供的讓開發人員更方便地進行協做的功能，提供了友好的Web界面可以在提議的改動合併到正式項目以前對改動進行討論。

開發人員向團隊成員通知功能開發已經完畢，Pull Requests是最簡單的使用方法。
開發人員完畢功能開發後。經過Bitbucket帳號發起一個Pull Request。
這樣讓涉及這個功能的所有人知道要去作Code Review和合併到master分支。

但是。Pull Request遠不止一個簡單的通知，而是爲討論提交的功能的一個專門論壇。
假設變動有不論什麼問題，團隊成員反饋在Pull Request中，甚至push新的提交微調功能。

所有的這些活動都直接跟蹤在Pull Request中。

相比其餘的協做模型，這樣的分享提交的形式有助於打造一個更流暢的工做流。
SVN和Git都能經過一個簡單的腳本收到通知郵件；但是，討論變動時，開發人員一般僅僅能去回覆郵件。
這樣作會變得雜亂。尤爲還要涉及後面的幾個提交時。
Pull Requests把所有相關功能整合到一個和Bitbucket倉庫界面集成的用戶友好Web界面中。

2.5.1 解析Pull Request

當要發起一個Pull Request，你所要作的就是請求（Request）還有一個開發人員（比方項目的維護者）
來pull你倉庫中一個分支到他的倉庫中。這意味着你要提供4個信息以發起Pull Request：
源倉庫、源分支、目的倉庫、目的分支。

這幾值多數Bitbucket都會設置上合適的缺省值。

但取決你用的協做工做流，你的團隊可能會要指定不一樣的值。

上圖顯示了一個Pull Request請求合併一個功能分支到正式的master分支上，但可以有多種不一樣的Pull Request使用方法。

2.5.2 工做方式

Pull Request可以和功能分支工做流、Gitflow工做流或Forking工做流一塊兒使用。
但一個Pull Request要求要麼分支不一樣要麼倉庫不一樣，因此不能用於集中式工做流。
在不一樣的工做流中使用Pull Request會有一些不一樣，但主要的過程是這種：

1. 開發人員在本地倉庫中新建一個專門的分支開發功能。
2. 開發人員push分支改動到公開的Bitbucket倉庫中。
3. 開發人員經過Bitbucket發起一個Pull Request。
4. 團隊的其餘成員review code，討論並改動。
5. 項目維護者合併功能到官方倉庫中並關閉Pull Request。

本文後面內容說明，Pull Request在不一樣協做工做流中怎樣應用。

2.5.3 在功能分支工做流中使用Pull Request

功能分支工做流用一個共享的Bitbucket倉庫來管理協做，開發人員在專門的分支上開發功能。
但不是立刻合併到master分支上，而是在合併到主代碼庫以前開發人員應該開一個Pull Request發起功能的討論。

功能分支工做流僅僅有一個公開的倉庫，因此Pull Request的目的倉庫和源倉庫老是同一個。
一般開發人員會指定他的功能分支做爲源分支，master分支做爲目的分支。

收到Pull Request後，項目維護者要決定怎樣作。

假設功能沒問題，就簡單地合併到master分支。關閉Pull Request。
但假設提交的變動有問題，他可以在Pull Request中反饋。以後新加的提交也會評論以後接着顯示出來。

在功能尚未全然開發完的時候，也可能發起一個Pull Request。
比方開發人員在實現某個需求時碰到了麻煩。他可以發一個包括正在進行中工做的Pull Request。
其餘的開發人員可以在Pull Request提供建議。或者甚至直接加入提交來解決這個問題。

2.5.4 在Gitflow工做流中使用Pull Request

Gitflow工做流和功能分支工做流相似。但環繞項目公佈定義一個嚴格的分支模型。
在Gitflow工做流中使用Pull Request讓開發人員在公佈分支或是維護分支上工做時，
可以有個方便的地方對關於公佈分支或是維護分支的問題進行交流。

Gitflow工做流中Pull Request的使用過程和上一節中全然一致：
當一個功能、公佈或是熱修復分支需要Review時。開發人員簡單發起一個Pull Request。
團隊的其餘成員會經過Bitbucket收到通知。

新功能通常合併到develop分支。而公佈和熱修復則要同一時候合併到develop分支和master分支上。

Pull Request可能用作所有合併的正式管理。

2.5.5 在Forking工做流中使用Pull Request

在Forking工做流中，開發人員push完畢的功能到他本身的倉庫中，而不是共享倉庫。
而後。他發起一個Pull Request。讓項目維護者知道他的功能已經可以Review了。

在這個工做流，Pull Request的通知功能很實用，
因爲項目維護者不可能知道其餘開發人員在他們本身的倉庫加入了提交。

由於各個開發有本身的公開倉庫，Pull Request的源倉庫和目標倉庫不是同一個。
源倉庫是開發人員的公開倉庫。源分支是包括了改動的分支。
假設開發人員要合併改動到正式代碼庫中，那麼目標倉庫是正式倉庫。目標分支是master分支。

Pull Request也可以用於正式項目以外的其餘開發人員之間的協做。
比方，假設一個開發人員和一個團隊成員一塊兒開發一個功能，他們可以發起一個Pull Request，
用團隊成員的Bitbucket倉庫做爲目標。而不是正式項目的倉庫。
而後使用一樣的功能分支做爲源和目標分支。

2個開發人員之間可以在Pull Request中討論和開發功能。
完畢開發後，他們可以發起還有一個Pull Request，請求合併功能到正式的master分支。
在Forking工做流中，這種靈活性讓Pull Request成爲一個強有力的協做工具。

2.5.6 演示樣例

如下的演示樣例演示了Pull Request怎樣在在Forking工做流中使用。
也相同適用於小團隊的開發協做和第三方開發人員向開源項目的貢獻。

在演示樣例中，小紅是個開發，小明是項目維護者。

他們各自有一個公開的Bitbucket倉庫，而小明的倉庫包括了正式project。

小紅fork正式項目

小紅先要fork小明的Bitbucket倉庫，開始項目的開發。

她登錄Bitbucket，瀏覽到小明的倉庫頁面，
點Forkbutton。

而後爲fork出來的倉庫填寫名字和描寫敘述，這樣小紅就有了服務端的項目拷貝了。

小紅克隆她的Bitbucket倉庫

下一步，小紅克隆本身剛纔fork出來的Bitbucket倉庫，以在本機上準備出工做拷貝。命令例如如下：

git clone https://user@bitbucket.org/user/repo.git

請記住。git clone會本身主動建立origin遠程別名，是指向小紅fork出來的倉庫。

小紅開發新功能

在開始改代碼前，小紅要爲新功能先新建一個新分支。她會用這個分支做爲Pull Request的源分支。

git checkout -b some-feature
# 編輯代碼
git commit -a -m "Add first draft of some feature"

在新功能分支上。小紅按需要加入提交。甚至假設小紅認爲功能分支上的提交歷史太亂了，她可以用交互式rebase來刪除或壓制提交。
對於大型項目，整理功能分支的歷史可以讓項目維護者更easy看出在Pull Request中作了什麼內容。

小紅push功能到她的Bitbucket倉庫中

小紅完畢了功能後，push功能到她本身的Bitbucket倉庫中（不是正式倉庫）。用如下簡單的命令：

git push origin some-branch

這時她的變動可以讓項目維護者看到了（或者不論什麼想要看的協做者）。

小紅髮起Pull Request

Bitbucket上有了她的功能分支後，小紅可以用她的Bitbucket帳號瀏覽到她的fork出來的倉庫頁面，
點右上角的【Pull Request】button，發起一個Pull Request。
彈出的表單本身主動設置小紅的倉庫爲源倉庫，詢問小紅以指定源分支、目標倉庫和目標分支。

小紅想要合併功能到正式倉庫。因此源分支是她的功能分支，目標倉庫是小明的公開倉庫，
而目標分支是master分支。另外。小紅需要提供Pull Request的標題和描寫敘述信息。
假設需要小明之外的人審覈批准代碼。她可以把這些人填在【Reviewers】文本框中。

建立好了Pull Request，通知會經過Bitbucket系統消息或郵件（可選）發給小明。

小明review Pull Request

在小明的Bitbucket倉庫頁面的【Pull Request】Tab可以看到所有人發起的Pull Request。
點擊小紅的Pull Request會顯示出Pull Request的描寫敘述、功能的提交歷史和每個變動的差別（diff）。

假設小明想要合併到項目中，僅僅要點一下【Merge】button。就可以容許Pull Request併合併到master分支。

但假設像這個演示樣例中同樣小明發現了在小紅的代碼中的一個小Bug。要小紅在合併前修復。
小明可以在整個Pull Request上加上評註。或是選擇歷史中的某個提交加上評註。

小紅補加提交

假設小紅對反饋有不論什麼疑問。可以在Pull Request中響應。把Pull Request看成是她功能討論的論壇。

小紅在她的功能分支新加提交以解決代碼問題，並push到她的Bitbucket倉庫中。就像前一輪中的作法同樣。
這些提交會進入的Pull Request。小明在原來的評註旁邊可以再次review變動。

小明接受Pull Request

終於，小明接受變動，合併功能分支到master分支，並關閉Pull Request。

至此，功能集成到項目中，其餘的項目開發人員可以用標準的git pull命令pull這些變動到本身的本地倉庫中。

到了這裏，你應該有了所有需要的工具來集成Pull Request到你本身的工做流。
請記住，Pull Request並不是爲了替代不論什麼 基於Git的協做工做流， 而是它們的一個便利的補充，讓團隊成員間的協做更輕鬆方便。