Paste_Image.png

]](http://blog.jobbole.com/76861/)

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

效果就是一個分布式的工作流，能為大型、自發性的團隊（包括了不受信的第三方）提供靈活的方式來安全的協作。也讓這個工作流成為開源項目的理想工作流。

工作方式

1. 一個新的開發者想要參與開發這個項目時，要fork正式項目在服務器上創建一個拷貝。這個倉庫拷貝作為他個人公開倉庫 —— 其它開發者不允許push到這個倉庫，但可以pull到修改。在創建了自己服務端拷貝之后，和之前的工作流一樣，開發者執行git clone命令克隆倉庫到本地機器上，作為私有的開發環境。
2. 要提交本地修改時，push提交到自己公開倉庫中 —— 而不是正式倉庫中。然后，給正式倉庫發起一個pull request。
3. 維護者pull貢獻者的變更到自己的本地倉庫中，檢查變更以確保不會讓項目出錯，合并變更到自己本地的master分支，然后pushmaster分支到服務器的正式倉庫中。到此，貢獻的提交成為了項目的一部分，其它的開發者應該執行pull操作與正式倉庫同步自己本地倉庫。

*其他方面內容與功能分支工作流和Gitflow工作流一樣。

、
Pull Request工作流

Pull Requests是Bitbucket上方便開發者之間協作的功能。提供了一個用戶友好的Web界面，在集成提交的變更到正式項目前可以對變更進行討論。

功能

1. 通知功能開發已經完成
2. 完成Code Review和合并到master分支
3. 為討論提交的功能提供一個專門論壇
4. 有助于打造一個更流暢的工作流

工作方式

基本過程：

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

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

功能分支工作流只有一個公開的倉庫，所以Pull Request的目的倉庫和源倉庫總是同一個。通常開發者會指定他的功能分支作為源分支，master分支作為目的分支。
收到Pull Request后，項目維護者要決定如何做。如果功能沒問題，就簡單地合并到master分支，關閉Pull Request。但如果提交的變更有問題，他可以在Pull Request中反饋。之后新加的提交也會評論之后接著顯示出來。
在功能還沒有完全開發完的時候，也可能發起一個Pull Request。比如開發者在實現某個需求時碰到了麻煩，他可以發一個包含正在進行中工作的Pull Request。其它的開發者可以在Pull Request提供建議，或者甚至直接添加提交來解決問題.

在Gitflow工作流中使用Pull Request

新功能一般合并到develop分支，而發布和熱修復則要同時合并到develop分支和master分支上。Pull Request
可能用做所有合并的正式管理。

在Forking工作流中使用Pull Request

由于各個開發有自己的公開倉庫，Pull Request的源倉庫和目標倉庫不是同一個。源倉庫是開發者的公開倉庫，源分支是包含了修改的分支。如果開發者要合并修改到正式代碼庫中，那么目標倉庫是正式倉庫，目標分支master分支。

Pull Request也可以用于正式項目之外的其它開發者之間的協作。比如，如果一個開發者和一個團隊成員一起開發一個功能，他們可以發起一個Pull Request，用團隊成員的Bitbucket倉庫作為目標，而不是正式項目的倉庫。然后使用相同的功能分支作為源和目標分支。

2個開發者之間可以在Pull Request中討論和開發功能。完成開發后，他們可以發起另一個Pull Request，請求合并功能到正式的master分支。在Forking工作流中，這樣的靈活性讓Pull Request成為一個強有力的協作工具。