git的操作说明超详细
2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>
說(shuō)明：
個(gè)人在學(xué)習(xí)Git工作流的過(guò)程中，從原有的 SVN 模式很難完全理解Git的協(xié)作模式，直到有一天我看到了下面的文章，好多遺留在心中的困惑迎刃而解：
- 我們以使用SVN的工作流來(lái)使用Git有什么不妥？
- Git方便的branch在哪里，團(tuán)隊(duì)多人如何協(xié)作？沖突了怎么辦？如何進(jìn)行發(fā)布控制？
- 經(jīng)典的master-發(fā)布、develop-主開發(fā)、hotfix-bug修復(fù)如何避免代碼不經(jīng)過(guò)驗(yàn)證上線？
- 如何在GitHub上面與他人一起協(xié)作，star-fork-pull request是怎樣的流程？
我個(gè)人很感激這篇文章，所以進(jìn)行了整理，希望能幫到更多的人。整篇文章由?xirong?整理自?oldratlee?的GitHub，方便統(tǒng)一的學(xué)習(xí)回顧，在此感謝下面兩位的貢獻(xiàn)。
原文鏈接：Git Workflows and Tutorials
簡(jiǎn)體中文：由?oldratlee?翻譯在?GitHub?上?Git工作流指南
在第三部分?企業(yè)日常開發(fā)模式探索，xirong 結(jié)合自己所在公司使用git的版本分支開發(fā)過(guò)程，進(jìn)行了總結(jié)，歡迎大家提出更好的建議。
在第四部分?開發(fā)工作流的討論?中，引用了幾篇文章，包括 Github 的開發(fā)流程以及 Thoughtworkers 工程師發(fā)表的「Gitflow 有害論」，旨在表名流程并不是唯一的，適合自己當(dāng)前團(tuán)隊(duì)的才是最好的。
?
- 一、譯序
- 二、Git工作流指南
- 2.1 集中式工作流
- 2.1.1 工作方式
- 2.1.2 沖突解決
- 2.1.3 示例
- 有人先初始化好中央倉(cāng)庫(kù)
- 所有人克隆中央倉(cāng)庫(kù)
- 小明開發(fā)功能
- 小紅開發(fā)功能
- 小明發(fā)布功能
- 小紅試著發(fā)布功能
- 小紅在小明的提交之上rebase
- 小紅解決合并沖突
- 小紅成功發(fā)布功能
- 2.2 功能分支工作流
- 2.2.1 工作方式
- 2.2.2 Pull Requests
- 2.2.3 示例
- 小紅開始開發(fā)一個(gè)新功能
- 小紅要去吃個(gè)午飯
- 小紅完成功能開發(fā)
- 小黑收到Pull Request
- 小紅再做修改
- 小紅發(fā)布她的功能
- 與此同時(shí)，小明在做和小紅一樣的事
- 2.3 Gitflow工作流
- 2.3.1 工作方式
- 2.3.2 歷史分支
- 2.3.3 功能分支
- 2.3.4 發(fā)布分支
- 2.3.5 維護(hù)分支
- 2.3.6 示例
- 創(chuàng)建開發(fā)分支
- 小紅和小明開始開發(fā)新功能
- 小紅完成功能開發(fā)
- 小紅開始準(zhǔn)備發(fā)布
- 小紅完成發(fā)布
- 最終用戶發(fā)現(xiàn)Bug
- 2.4 Forking工作流
- 2.4.1 工作方式
- 2.4.2 正式倉(cāng)庫(kù)
- 2.4.3 Forking工作流的分支使用方式
- 2.4.4 示例
- 項(xiàng)目維護(hù)者初始化正式倉(cāng)庫(kù)
- 開發(fā)者fork正式倉(cāng)庫(kù)
- 開發(fā)者克隆自己fork出來(lái)的倉(cāng)庫(kù)
- 開發(fā)者開發(fā)自己的功能
- 開發(fā)者發(fā)布自己的功能
- 項(xiàng)目維護(hù)者集成開發(fā)者的功能
- 開發(fā)者和正式倉(cāng)庫(kù)做同步
- 2.5 Pull Requests
- 2.5.1 解析Pull Request
- 2.5.2 工作方式
- 2.5.3 在功能分支工作流中使用Pull Request
- 2.5.4 在Gitflow工作流中使用Pull Request
- 2.5.5 在Forking工作流中使用Pull Request
- 2.5.6 示例
- 小紅fork正式項(xiàng)目
- 小紅克隆她的Bitbucket倉(cāng)庫(kù)
- 小紅開發(fā)新功能
- 小紅push功能到她的Bitbucket倉(cāng)庫(kù)中
- 小紅發(fā)起Pull Request
- 小明review Pull Request
- 小紅補(bǔ)加提交
- 小明接受Pull Request
- 2.1 集中式工作流
- 三、企業(yè)日常開發(fā)模式探索
?
一、譯序
這篇指南以大家在SVN中已經(jīng)廣為熟悉使用的集中式工作流作為起點(diǎn)，循序漸進(jìn)地演進(jìn)到其它高效的分布式工作流，還介紹了如何配合使用便利的Pull Request功能，系統(tǒng)地講解了各種工作流的應(yīng)用。 如果你Git用的還不多，可以從前面的講的工作流開始操練。在操作過(guò)程中去感受指南的講解：解決什么問(wèn)題、如何解決問(wèn)題，這樣理解就深了，也方便活用。
行文中實(shí)踐原則和操作示例并重，對(duì)于Git的資深玩家可以梳理思考提升，而新接觸的同學(xué)，也可以跟著step-by-step操練學(xué)習(xí)并在實(shí)際工作中上手使用。
工作流其實(shí)不是一個(gè)初級(jí)主題，背后的本質(zhì)問(wèn)題是 有效的項(xiàng)目流程管理 和 高效的開發(fā)協(xié)同約定，而不僅僅是Git或SVN等VCS或SCM工具的使用。
關(guān)于Git工作流主題，網(wǎng)上體系的中文資料不多，主要是零散的操作說(shuō)明，希望這篇文章能讓你更深入理解并在工作中靈活有效地使用起來(lái)。
Gitflow工作流是經(jīng)典模型，處于核心位置，體現(xiàn)了工作流的經(jīng)驗(yàn)和精髓。隨著項(xiàng)目過(guò)程復(fù)雜化，你會(huì)感受到這個(gè)工作流中的深思熟慮和威力！
Forking工作流是分布式協(xié)作的（GitHub風(fēng)格）可以先看看GitHub的Help：Fork A Repo和Using pull requests?。照著操作，給一個(gè)GitHub項(xiàng)目貢獻(xiàn)你的提交，有操作經(jīng)驗(yàn)再看指南容易意會(huì)。指南中給了自己實(shí)現(xiàn)Fork的方法：Fork就是服務(wù)端的克隆。在指南的操練中使用代碼托管服務(wù)（如GitHub、Bitbucket），可以點(diǎn)一下按鈕就讓開發(fā)者完成倉(cāng)庫(kù)的fork操作。
PS：
文中Pull Request的介紹用的是Bitbucket代碼托管服務(wù)，由于和GitHub基本一樣，如果你用的是GitHub（我自己也主要使用GitHub托管代碼），不影響理解和操作。
PPS：
更多Git學(xué)習(xí)資料參見
- Git的資料整理?by?@xirong
- 自己整理的分享PPT?Git使用與實(shí)踐?@?個(gè)人整理一些Git
- ?自己理解粗淺，翻譯中不足和不對(duì)之處，歡迎?
- 建議，提交Issue
- 指正，Fork后提通過(guò)Pull Requst貢獻(xiàn)修改
- 如有文章理解上有疑問(wèn) 或是 使用過(guò)程中碰到些疑惑，請(qǐng)隨時(shí)提交Issue?，一起交流學(xué)習(xí)討論！
二、Git工作流指南
?工作流有各式各樣的用法，但也正因此使得在實(shí)際工作中如何上手使用變得很頭大。這篇指南通過(guò)總覽公司團(tuán)隊(duì)中最常用的幾種Git工作流讓大家可以上手使用。
在閱讀的過(guò)程中請(qǐng)記住，本文中的幾種工作流是作為方案指導(dǎo)而不是條例規(guī)定。在展示了各種工作流可能的用法后，你可以從不同的工作流中挑選或揉合出一個(gè)滿足你自己需求的工作流。
2.1 集中式工作流
如果你的開發(fā)團(tuán)隊(duì)成員已經(jīng)很熟悉Subversion，集中式工作流讓你無(wú)需去適應(yīng)一個(gè)全新流程就可以體驗(yàn)Git帶來(lái)的收益。這個(gè)工作流也可以作為向更Git風(fēng)格工作流遷移的友好過(guò)渡。?
轉(zhuǎn)到分布式版本控制系統(tǒng)看起來(lái)像個(gè)令人生畏的任務(wù)，但不改變已用的工作流，你也可以用上Git帶來(lái)的收益。團(tuán)隊(duì)可以用和Subversion完全不變的方式來(lái)開發(fā)項(xiàng)目。
但使用Git加強(qiáng)開發(fā)的工作流，相比SVN，Git有以下兩個(gè)優(yōu)勢(shì): 首先，每個(gè)開發(fā)者可以有屬于自己的整個(gè)工程的本地拷貝。隔離的環(huán)境讓各個(gè)開發(fā)者的工作和項(xiàng)目的其他部分修改獨(dú)立開來(lái) —— 即自由地提交到自己的本地倉(cāng)庫(kù)，先完全忽略上游的開發(fā)，直到方便的時(shí)候再把修改反饋上去。
其次，Git提供了強(qiáng)壯的分支和合并模型。不像SVN，Git的分支設(shè)計(jì)成可以做為一種用來(lái)在倉(cāng)庫(kù)之間集成代碼和分享修改的『失敗安全』的機(jī)制。
2.1.1 工作方式
像Subversion一樣，集中式工作流以中央倉(cāng)庫(kù)作為項(xiàng)目所有修改的單點(diǎn)實(shí)體。相比SVN缺省的開發(fā)分支trunk，Git叫做master，所有修改提交到這個(gè)分支上。本工作流只用到master這一個(gè)分支。
首先，開發(fā)者克隆中央倉(cāng)庫(kù)。在自己的項(xiàng)目拷貝中，像SVN一樣的編輯文件和提交修改；但修改是存在本地的，和中央倉(cāng)庫(kù)是完全隔離的。開發(fā)者可以把和上游的同步延后到一個(gè)方便時(shí)間點(diǎn)。
然后，開發(fā)者發(fā)布修改到正式項(xiàng)目中，開發(fā)者要把本地master分支的修改『推』到中央倉(cāng)庫(kù)中。這相當(dāng)于svn commit操作，但push操作會(huì)把所有還不在中央倉(cāng)庫(kù)的本地提交都推上去。
2.1.2 沖突解決
中央倉(cāng)庫(kù)代表了正式項(xiàng)目，所以提交歷史應(yīng)該被尊重且是穩(wěn)定不變的。如果開發(fā)者本地的提交歷史和中央倉(cāng)庫(kù)有分歧，Git會(huì)拒絕push提交否則會(huì)覆蓋已經(jīng)在中央庫(kù)的正式提交。
在開發(fā)者提交自己功能修改到中央庫(kù)前，需要先f(wàn)etch在中央庫(kù)的新增提交，rebase自己提交到中央庫(kù)提交歷史之上。 這樣做的意思是在說(shuō)，『我要把自己的修改加到別人已經(jīng)完成的修改上。』最終的結(jié)果是一個(gè)完美的線性歷史，就像以前的SVN的工作流中一樣。
如果本地修改和上游提交有沖突，Git會(huì)暫停rebase過(guò)程，給你手動(dòng)解決沖突的機(jī)會(huì)。Git解決合并沖突，用和生成提交一樣的git status和git add命令，很一致方便。還有一點(diǎn)，如果解決沖突時(shí)遇到麻煩，Git可以很簡(jiǎn)單中止整個(gè)rebase操作，重來(lái)一次（或者讓別人來(lái)幫助解決）。
2.1.3 示例
讓我們一起逐步分解來(lái)看看一個(gè)常見的小團(tuán)隊(duì)如何用這個(gè)工作流來(lái)協(xié)作的。有兩個(gè)開發(fā)者小明和小紅，看他們是如何開發(fā)自己的功能并提交到中央倉(cāng)庫(kù)上的。
有人先初始化好中央倉(cāng)庫(kù)
第一步，有人在服務(wù)器上創(chuàng)建好中央倉(cāng)庫(kù)。如果是新項(xiàng)目，你可以初始化一個(gè)空倉(cāng)庫(kù)；否則你要導(dǎo)入已有的Git或SVN倉(cāng)庫(kù)。
中央倉(cāng)庫(kù)應(yīng)該是個(gè)裸倉(cāng)庫(kù)（bare repository），即沒(méi)有工作目錄（working directory）的倉(cāng)庫(kù)。可以用下面的命令創(chuàng)建：
ssh user@host git init --bare /path/to/repo.git確保寫上有效的user（SSH的用戶名），host（服務(wù)器的域名或IP地址），/path/to/repo.git（你想存放倉(cāng)庫(kù)的位置）。 注意，為了表示是一個(gè)裸倉(cāng)庫(kù)，按照約定加上.git擴(kuò)展名到倉(cāng)庫(kù)名上。
所有人克隆中央倉(cāng)庫(kù)
下一步，各個(gè)開發(fā)者創(chuàng)建整個(gè)項(xiàng)目的本地拷貝。通過(guò)git clone命令完成：
git clone ssh://user@host/path/to/repo.git基于你后續(xù)會(huì)持續(xù)和克隆的倉(cāng)庫(kù)做交互的假設(shè)，克隆倉(cāng)庫(kù)時(shí)Git會(huì)自動(dòng)添加遠(yuǎn)程別名origin指回『父』倉(cāng)庫(kù)。
小明開發(fā)功能
在小明的本地倉(cāng)庫(kù)中，他使用標(biāo)準(zhǔn)的Git過(guò)程開發(fā)功能：編輯、暫存（Stage）和提交。 如果你不熟悉暫存區(qū)（Staging Area），這里說(shuō)明一下：暫存區(qū)用來(lái)準(zhǔn)備一個(gè)提交，但可以不用把工作目錄中所有的修改內(nèi)容都包含進(jìn)來(lái)。 這樣你可以創(chuàng)建一個(gè)高度聚焦的提交，盡管你本地修改很多內(nèi)容。
git status # 查看本地倉(cāng)庫(kù)的修改狀態(tài) git add # 暫存文件 git commit # 提交文件請(qǐng)記住，因?yàn)檫@些命令生成的是本地提交，小明可以按自己需求反復(fù)操作多次，而不用擔(dān)心中央倉(cāng)庫(kù)上有了什么操作。 對(duì)需要多個(gè)更簡(jiǎn)單更原子分塊的大功能，這個(gè)做法是很有用的。
小紅開發(fā)功能
與此同時(shí)，小紅在自己的本地倉(cāng)庫(kù)中用相同的編輯、暫存和提交過(guò)程開發(fā)功能。和小明一樣，她也不關(guān)心中央倉(cāng)庫(kù)有沒(méi)有新提交； 當(dāng)然更不關(guān)心小明在他的本地倉(cāng)庫(kù)中的操作，因?yàn)樗斜镜貍}(cāng)庫(kù)都是私有的。
小明發(fā)布功能
一旦小明完成了他的功能開發(fā)，會(huì)發(fā)布他的本地提交到中央倉(cāng)庫(kù)中，這樣其它團(tuán)隊(duì)成員可以看到他的修改。他可以用下面的git push命令：
git push origin master注意，origin是在小明克隆倉(cāng)庫(kù)時(shí)Git創(chuàng)建的遠(yuǎn)程中央倉(cāng)庫(kù)別名。master參數(shù)告訴Git推送的分支。 由于中央倉(cāng)庫(kù)自從小明克隆以來(lái)還沒(méi)有被更新過(guò)，所以push操作不會(huì)有沖突，成功完成。
小紅試著發(fā)布功能
一起來(lái)看看在小明發(fā)布修改后，小紅push修改會(huì)怎么樣？她使用完全一樣的push命令：
git push origin master但她的本地歷史已經(jīng)和中央倉(cāng)庫(kù)有分岐了，Git拒絕操作并給出下面很長(zhǎng)的出錯(cuò)消息：
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小明的更新到她的本地倉(cāng)庫(kù)合并上她的本地修改后，再重試。
小紅在小明的提交之上rebase
小紅用git pull合并上游的修改到自己的倉(cāng)庫(kù)中。 這條命令類似svn update——拉取所有上游提交命令到小紅的本地倉(cāng)庫(kù)，并嘗試和她的本地修改合并：
git pull --rebase origin master--rebase選項(xiàng)告訴Git把小紅的提交移到同步了中央倉(cāng)庫(kù)修改后的master分支的頂部，如下圖所示：
如果你忘加了這個(gè)選項(xiàng)，pull操作仍然可以完成，但每次pull操作要同步中央倉(cāng)庫(kù)中別人修改時(shí)，提交歷史會(huì)以一個(gè)多余的『合并提交』結(jié)尾。 對(duì)于集中式工作流，最好是使用rebase而不是生成一個(gè)合并提交。
小紅解決合并沖突
rebase操作過(guò)程是把本地提交一次一個(gè)地遷移到更新了的中央倉(cāng)庫(kù)master分支之上。 這意味著可能要解決在遷移某個(gè)提交時(shí)出現(xiàn)的合并沖突，而不是解決包含了所有提交的大型合并時(shí)所出現(xiàn)的沖突。 這樣的方式讓你盡可能保持每個(gè)提交的聚焦和項(xiàng)目歷史的整潔。反過(guò)來(lái)，簡(jiǎn)化了哪里引入Bug的分析，如果有必要，回滾修改也可以做到對(duì)項(xiàng)目影響最小。
如果小紅和小明的功能是不相關(guān)的，不大可能在rebase過(guò)程中有沖突。如果有，Git在合并有沖突的提交處暫停rebase過(guò)程，輸出下面的信息并帶上相關(guān)的指令：
CONFLICT (content): Merge conflict in <some-file>Git很贊的一點(diǎn)是，任何人可以解決他自己的沖突。在這個(gè)例子中，小紅可以簡(jiǎn)單的運(yùn)行g(shù)it status命令來(lái)查看哪里有問(wèn)題。 沖突文件列在Unmerged paths（未合并路徑）一節(jié)中：
# 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會(huì)繼續(xù)一個(gè)一個(gè)地合并后面的提交，如其它的提交有沖突就重復(fù)這個(gè)過(guò)程。
如果你碰到了沖突，但發(fā)現(xiàn)搞不定，不要驚慌。只要執(zhí)行下面這條命令，就可以回到你執(zhí)行g(shù)it pull --rebase命令前的樣子：
git rebase --abort小紅成功發(fā)布功能
小紅完成和中央倉(cāng)庫(kù)的同步后，就能成功發(fā)布她的修改了：
git push origin master如你所見，僅使用幾個(gè)Git命令我們就可以模擬出傳統(tǒng)Subversion開發(fā)環(huán)境。對(duì)于要從SVN遷移過(guò)來(lái)的團(tuán)隊(duì)來(lái)說(shuō)這太好了，但沒(méi)有發(fā)揮出Git分布式本質(zhì)的優(yōu)勢(shì)。
如果你的團(tuán)隊(duì)適應(yīng)了集中式工作流，但想要更流暢的協(xié)作效果，絕對(duì)值得探索一下?功能分支工作流?的收益。 通過(guò)為一個(gè)功能分配一個(gè)專門的分支，能夠做到一個(gè)新增功能集成到正式項(xiàng)目之前對(duì)新功能進(jìn)行深入討論。
2.2 功能分支工作流
功能分支工作流以集中式工作流為基礎(chǔ)，不同的是為各個(gè)新功能分配一個(gè)專門的分支來(lái)開發(fā)。這樣可以在把新功能集成到正式項(xiàng)目前，用Pull Requests的方式討論變更。
一旦你玩轉(zhuǎn)了集中式工作流，在開發(fā)過(guò)程中可以很簡(jiǎn)單地加上功能分支，用來(lái)鼓勵(lì)開發(fā)者之間協(xié)作和簡(jiǎn)化交流。
功能分支工作流背后的核心思路是所有的功能開發(fā)應(yīng)該在一個(gè)專門的分支，而不是在master分支上。 這個(gè)隔離可以方便多個(gè)開發(fā)者在各自的功能上開發(fā)而不會(huì)弄亂主干代碼。 另外，也保證了master分支的代碼一定不會(huì)是有問(wèn)題的，極大有利于集成環(huán)境。
功能開發(fā)隔離也讓pull requests工作流成功可能，?pull requests工作流能為每個(gè)分支發(fā)起一個(gè)討論，在分支合入正式項(xiàng)目之前，給其它開發(fā)者有表示贊同的機(jī)會(huì)。 另外，如果你在功能開發(fā)中有問(wèn)題卡住了，可以開一個(gè)pull requests來(lái)向同學(xué)們征求建議。 這些做法的重點(diǎn)就是，pull requests讓團(tuán)隊(duì)成員之間互相評(píng)論工作變成非常方便！
2.2.1 工作方式
功能分支工作流仍然用中央倉(cāng)庫(kù)，并且master分支還是代表了正式項(xiàng)目的歷史。 但不是直接提交本地歷史到各自的本地master分支，開發(fā)者每次在開始新功能前先創(chuàng)建一個(gè)新分支。 功能分支應(yīng)該有個(gè)有描述性的名字，比如animated-menu-items或issue-#1061，這樣可以讓分支有個(gè)清楚且高聚焦的用途。
對(duì)于master分支和功能分支，Git是沒(méi)有技術(shù)上的區(qū)別，所以開發(fā)者可以用和集中式工作流中完全一樣的方式編輯、暫存和提交修改到功能分支上。
另外，功能分支也可以（且應(yīng)該）push到中央倉(cāng)庫(kù)中。這樣不修改正式代碼就可以和其它開發(fā)者分享提交的功能。 由于master是僅有的一個(gè)『特殊』分支，在中央倉(cāng)庫(kù)上存多個(gè)功能分支不會(huì)有任何問(wèn)題。當(dāng)然，這樣做也可以很方便地備份各自的本地提交。
2.2.2?Pull Requests
功能分支除了可以隔離功能的開發(fā)，也使得通過(guò)Pull Requests討論變更成為可能。 一旦某個(gè)開發(fā)者完成一個(gè)功能，不是立即合并到master，而是push到中央倉(cāng)庫(kù)的功能分支上并發(fā)起一個(gè)Pull Request請(qǐng)求，將修改合并到master。 在修改成為主干代碼前，這讓其它的開發(fā)者有機(jī)會(huì)先去Review變更。
Code Review是Pull Requests的一個(gè)重要的收益，而Pull Requests則是討論代碼的一個(gè)通用方式。 你可以把Pull Requests作為專門給某個(gè)分支的討論。這意味著可以在更早的開發(fā)過(guò)程中就可以進(jìn)行Code Review。 比如，一個(gè)開發(fā)者開發(fā)功能需要幫助時(shí)，要做的就是發(fā)起一個(gè)Pull Request，相關(guān)的人就會(huì)自動(dòng)收到通知，在相關(guān)的提交旁邊能看到需要幫助解決的問(wèn)題。
一旦Pull Request被接受了，發(fā)布功能要做的就和集中式工作流就很像了。 首先，確定本地的master分支和上游的master分支是同步的。然后合并功能分支到本地master分支并push已經(jīng)更新的本地master分支到中央倉(cāng)庫(kù)。
倉(cāng)庫(kù)管理的產(chǎn)品解決方案像Bitbucket或Stash，可以良好地支持Pull Requests。可以看看Stash的Pull Requests文檔。
2.2.3 示例
下面的示例演示了如何把Pull Requests作為Code Review的方式，但注意Pull Requests可以用于很多其它的目的。
小紅開始開發(fā)一個(gè)新功能
在開始開發(fā)功能前，小紅需要一個(gè)獨(dú)立的分支。使用下面的命令新建一個(gè)分支：
git checkout -b marys-feature master這個(gè)命令檢出一個(gè)基于master名為marys-feature的分支，Git的-b選項(xiàng)表示如果分支還不存在則新建分支。 這個(gè)新分支上，小紅按老套路編輯、暫存和提交修改，按需要提交以實(shí)現(xiàn)功能：
git status git add <some-file> git commit小紅要去吃個(gè)午飯
早上小紅為新功能添加一些提交。 去吃午飯前，push功能分支到中央倉(cāng)庫(kù)是很好的做法，這樣可以方便地備份，如果和其它開發(fā)協(xié)作，也讓他們可以看到小紅的提交。
git push -u origin marys-feature這條命令push?marys-feature分支到中央倉(cāng)庫(kù)（origin），-u選項(xiàng)設(shè)置本地分支去跟蹤遠(yuǎn)程對(duì)應(yīng)的分支。 設(shè)置好跟蹤的分支后，小紅就可以使用git push命令省去指定推送分支的參數(shù)。
小紅完成功能開發(fā)
小紅吃完午飯回來(lái)，完成整個(gè)功能的開發(fā)。在合并到master之前， 她發(fā)起一個(gè)Pull Request讓團(tuán)隊(duì)的其它人知道功能已經(jīng)完成。但首先，她要確認(rèn)中央倉(cāng)庫(kù)中已經(jīng)有她最近的提交：
git push然后，在她的Git?GUI客戶端中發(fā)起Pull Request，請(qǐng)求合并marys-feature到master，團(tuán)隊(duì)成員會(huì)自動(dòng)收到通知。?Pull Request很酷的是可以在相關(guān)的提交旁邊顯示評(píng)注，所以你可以對(duì)某個(gè)變更集提問(wèn)。
小黑收到Pull Request
小黑收到了Pull Request后會(huì)查看marys-feature的修改。決定在合并到正式項(xiàng)目前是否要做些修改，且通過(guò)Pull Request和小紅來(lái)回地討論。
小紅再做修改
要再做修改，小紅用和功能第一個(gè)迭代完全一樣的過(guò)程。編輯、暫存、提交并push更新到中央倉(cāng)庫(kù)。小紅這些活動(dòng)都會(huì)顯示在Pull Request上，小黑可以斷續(xù)做評(píng)注。
如果小黑有需要，也可以把marys-feature分支拉到本地，自己來(lái)修改，他加的提交也會(huì)一樣顯示在Pull Request上。
小紅發(fā)布她的功能
一旦小黑可以的接受Pull Request，就可以合并功能到穩(wěn)定項(xiàng)目代碼中（可以由小黑或是小紅來(lái)做這個(gè)操作）：
git checkout master git pull git pull origin marys-feature git push無(wú)論誰(shuí)來(lái)做合并，首先要檢出master分支并確認(rèn)是它是最新的。然后執(zhí)行g(shù)it pull origin marys-feature合并marys-feature分支到和已經(jīng)和遠(yuǎn)程一致的本地master分支。 你可以使用簡(jiǎn)單git merge marys-feature命令，但前面的命令可以保證總是最新的新功能分支。 最后更新的master分支要重新push回到origin。
這個(gè)過(guò)程常常會(huì)生成一個(gè)合并提交。有些開發(fā)者喜歡有合并提交，因?yàn)樗褚粋€(gè)新功能和原來(lái)代碼基線的連通符。 但如果你偏愛線性的提交歷史，可以在執(zhí)行合并時(shí)rebase新功能到master分支的頂部，這樣生成一個(gè)快進(jìn)（fast-forward）的合并。
一些GUI客戶端可以只要點(diǎn)一下『接受』按鈕執(zhí)行好上面的命令來(lái)自動(dòng)化Pull Request接受過(guò)程。 如果你的不能這樣，至少在功能合并到master分支后能自動(dòng)關(guān)閉Pull Request。
與此同時(shí)，小明在做和小紅一樣的事
當(dāng)小紅和小黑在marys-feature上工作并討論她的Pull Request的時(shí)候，小明在自己的功能分支上做完全一樣的事。
通過(guò)隔離功能到獨(dú)立的分支上，每個(gè)人都可以自主的工作，當(dāng)然必要的時(shí)候在開發(fā)者之間分享變更還是比較繁瑣的。
到了這里，但愿你發(fā)現(xiàn)了功能分支可以很直接地在?集中式工作流?的僅有的master分支上完成多功能的開發(fā)。 另外，功能分支還使用了Pull Request，使得可以在你的版本控制GUI客戶端中討論某個(gè)提交。
功能分支工作流是開發(fā)項(xiàng)目異常靈活的方式。問(wèn)題是，有時(shí)候太靈活了。對(duì)于大型團(tuán)隊(duì)，常常需要給不同分支分配一個(gè)更具體的角色。?Gitflow工作流是管理功能開發(fā)、發(fā)布準(zhǔn)備和維護(hù)的常用模式。
2.3?Gitflow工作流
Gitflow工作流通過(guò)為功能開發(fā)、發(fā)布準(zhǔn)備和維護(hù)分配獨(dú)立的分支，讓發(fā)布迭代過(guò)程更流暢。嚴(yán)格的分支模型也為大型項(xiàng)目提供了一些非常必要的結(jié)構(gòu)。
這節(jié)介紹的Gitflow工作流借鑒自在nvie的Vincent Driessen。
Gitflow工作流定義了一個(gè)圍繞項(xiàng)目發(fā)布的嚴(yán)格分支模型。雖然比功能分支工作流復(fù)雜幾分，但提供了用于一個(gè)健壯的用于管理大型項(xiàng)目的框架。
Gitflow工作流沒(méi)有用超出功能分支工作流的概念和命令，而是為不同的分支分配一個(gè)明確的角色，并定義分支之間如何和什么時(shí)候進(jìn)行交互。 除了使用功能分支，在做準(zhǔn)備、維護(hù)和記錄發(fā)布時(shí)，也定義了各自的分支。 當(dāng)然你可以用上功能分支工作流所有的好處：Pull Requests、隔離實(shí)驗(yàn)性開發(fā)和更高效的協(xié)作。
2.3.1 工作方式
Gitflow工作流仍然用中央倉(cāng)庫(kù)作為所有開發(fā)者的交互中心。和其它的工作流一樣，開發(fā)者在本地工作并push分支到要中央倉(cāng)庫(kù)中。
2.3.2 歷史分支
相對(duì)于使用僅有的一個(gè)master分支，Gitflow工作流使用兩個(gè)分支來(lái)記錄項(xiàng)目的歷史。master分支存儲(chǔ)了正式發(fā)布的歷史，而develop分支作為功能的集成分支。 這樣也方便master分支上的所有提交分配一個(gè)版本號(hào)。
剩下要說(shuō)明的問(wèn)題圍繞著這2個(gè)分支的區(qū)別展開。
2.3.3 功能分支
每個(gè)新功能位于一個(gè)自己的分支，這樣可以push到中央倉(cāng)庫(kù)以備份和協(xié)作。 但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。當(dāng)新功能完成時(shí)，合并回develop分支。 新功能提交應(yīng)該從不直接與master分支交互。
注意，從各種含義和目的上來(lái)看，功能分支加上develop分支就是功能分支工作流的用法。但Gitflow工作流沒(méi)有在這里止步。
2.3.4 發(fā)布分支
一旦develop分支上有了做一次發(fā)布（或者說(shuō)快到了既定的發(fā)布日）的足夠功能，就從develop分支上checkout一個(gè)發(fā)布分支。 新建的分支用于開始發(fā)布循環(huán)，所以從這個(gè)時(shí)間點(diǎn)開始之后新的功能不能再加到這個(gè)分支上—— 這個(gè)分支只應(yīng)該做Bug修復(fù)、文檔生成和其它面向發(fā)布任務(wù)。 一旦對(duì)外發(fā)布的工作都完成了，發(fā)布分支合并到master分支并分配一個(gè)版本號(hào)打好Tag。 另外，這些從新建發(fā)布分支以來(lái)的做的修改要合并回develop分支。
使用一個(gè)用于發(fā)布準(zhǔn)備的專門分支，使得一個(gè)團(tuán)隊(duì)可以在完善當(dāng)前的發(fā)布版本的同時(shí)，另一個(gè)團(tuán)隊(duì)可以繼續(xù)開發(fā)下個(gè)版本的功能。 這也打造定義良好的開發(fā)階段（比如，可以很輕松地說(shuō)，『這周我們要做準(zhǔn)備發(fā)布版本4.0』，并且在倉(cāng)庫(kù)的目錄結(jié)構(gòu)中可以實(shí)際看到）。
常用的分支約定：
用于新建發(fā)布分支的分支: develop 用于合并的分支: master 分支命名: release-* 或 release/*2.3.5 維護(hù)分支
維護(hù)分支或說(shuō)是熱修復(fù)（hotfix）分支用于給產(chǎn)品發(fā)布版本（production releases）快速生成補(bǔ)丁，這是唯一可以直接從master分支fork出來(lái)的分支。 修復(fù)完成，修改應(yīng)該馬上合并回master分支和develop分支（當(dāng)前的發(fā)布分支），master分支應(yīng)該用新的版本號(hào)打好Tag。
為Bug修復(fù)使用專門分支，讓團(tuán)隊(duì)可以處理掉問(wèn)題而不用打斷其它工作或是等待下一個(gè)發(fā)布循環(huán)。 你可以把維護(hù)分支想成是一個(gè)直接在master分支上處理的臨時(shí)發(fā)布。
2.3.6 示例
下面的示例演示本工作流如何用于管理單個(gè)發(fā)布循環(huán)。假設(shè)你已經(jīng)創(chuàng)建了一個(gè)中央倉(cāng)庫(kù)。
創(chuàng)建開發(fā)分支
第一步為master分支配套一個(gè)develop分支。簡(jiǎn)單來(lái)做可以本地創(chuàng)建一個(gè)空的develop分支，push到服務(wù)器上：
git branch develop git push -u origin develop以后這個(gè)分支將會(huì)包含了項(xiàng)目的全部歷史，而master分支將只包含了部分歷史。其它開發(fā)者這時(shí)應(yīng)該克隆中央倉(cāng)庫(kù)，建好develop分支的跟蹤分支：
git clone ssh://user@host/path/to/repo.git git checkout -b develop origin/develop現(xiàn)在每個(gè)開發(fā)都有了這些歷史分支的本地拷貝。
小紅和小明開始開發(fā)新功能
這個(gè)示例中，小紅和小明開始各自的功能開發(fā)。他們需要為各自的功能創(chuàng)建相應(yīng)的分支。新分支不是基于master分支，而是應(yīng)該基于develop分支：
git checkout -b some-feature develop他們用老套路添加提交到各自功能分支上：編輯、暫存、提交：
git status git add <some-file> git commit小紅完成功能開發(fā)
添加了提交后，小紅覺(jué)得她的功能OK了。如果團(tuán)隊(duì)使用Pull Requests，這時(shí)候可以發(fā)起一個(gè)用于合并到develop分支。 否則她可以直接合并到她本地的develop分支后push到中央倉(cāng)庫(kù)：
git pull origin develop git checkout develop git merge some-feature git push git branch -d some-feature第一條命令在合并功能前確保develop分支是最新的。注意，功能決不應(yīng)該直接合并到master分支。 沖突解決方法和集中式工作流一樣。
小紅開始準(zhǔn)備發(fā)布
這個(gè)時(shí)候小明正在實(shí)現(xiàn)他的功能，小紅開始準(zhǔn)備她的第一個(gè)項(xiàng)目正式發(fā)布。 像功能開發(fā)一樣，她用一個(gè)新的分支來(lái)做發(fā)布準(zhǔn)備。這一步也確定了發(fā)布的版本號(hào)：
git checkout -b release-0.1 develop這個(gè)分支是清理發(fā)布、執(zhí)行所有測(cè)試、更新文檔和其它為下個(gè)發(fā)布做準(zhǔn)備操作的地方，像是一個(gè)專門用于改善發(fā)布的功能分支。
只要小紅創(chuàng)建這個(gè)分支并push到中央倉(cāng)庫(kù)，這個(gè)發(fā)布就是功能凍結(jié)的。任何不在develop分支中的新功能都推到下個(gè)發(fā)布循環(huán)中。
小紅完成發(fā)布
一旦準(zhǔn)備好了對(duì)外發(fā)布，小紅合并修改到master分支和develop分支上，刪除發(fā)布分支。合并回develop分支很重要，因?yàn)樵诎l(fā)布分支中已經(jīng)提交的更新需要在后面的新功能中也要是可用的。 另外，如果小紅的團(tuán)隊(duì)要求Code Review，這是一個(gè)發(fā)起Pull Request的理想時(shí)機(jī)。
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發(fā)布分支是作為功能開發(fā)（develop分支）和對(duì)外發(fā)布（master分支）間的緩沖。只要有合并到master分支，就應(yīng)該打好Tag以方便跟蹤。
git tag -a 0.1 -m "Initial public release" master git push --tagsGit有提供各種勾子（hook），即倉(cāng)庫(kù)有事件發(fā)生時(shí)觸發(fā)執(zhí)行的腳本。 可以配置一個(gè)勾子，在你push中央倉(cāng)庫(kù)的master分支時(shí)，自動(dòng)構(gòu)建好版本，并對(duì)外發(fā)布。
最終用戶發(fā)現(xiàn)Bug
對(duì)外版本發(fā)布后，小紅小明一起開發(fā)下一版本的新功能，直到有最終用戶開了一個(gè)Ticket抱怨當(dāng)前版本的一個(gè)Bug。 為了處理Bug，小紅（或小明）從master分支上拉出了一個(gè)維護(hù)分支，提交修改以解決問(wèn)題，然后直接合并回master分支：
git checkout -b issue-#001 master # Fix the bug git checkout master git merge issue-#001 git push就像發(fā)布分支，維護(hù)分支中新加這些重要修改需要包含到develop分支中，所以小紅要執(zhí)行一個(gè)合并操作。然后就可以安全地刪除這個(gè)分支了：
git checkout develop git merge issue-#001 git push git branch -d issue-#001到了這里，但愿你對(duì)集中式工作流、功能分支工作流和Gitflow工作流已經(jīng)感覺(jué)很舒適了。 你應(yīng)該也牢固的掌握了本地倉(cāng)庫(kù)的潛能，push/pull模式和Git健壯的分支和合并模型。
記住，這里演示的工作流只是可能用法的例子，而不是在實(shí)際工作中使用Git不可違逆的條例。 所以不要畏懼按自己需要對(duì)工作流的用法做取舍。不變的目標(biāo)就是讓Git為你所用。
2.4?Forking工作流
Forking工作流是分布式工作流，充分利用了Git在分支和克隆上的優(yōu)勢(shì)。可以安全可靠地管理大團(tuán)隊(duì)的開發(fā)者（developer），并能接受不信任貢獻(xiàn)者（contributor）的提交。
Forking工作流和前面討論的幾種工作流有根本的不同，這種工作流不是使用單個(gè)服務(wù)端倉(cāng)庫(kù)作為『中央』代碼基線，而讓各個(gè)開發(fā)者都有一個(gè)服務(wù)端倉(cāng)庫(kù)。這意味著各個(gè)代碼貢獻(xiàn)者有2個(gè)Git倉(cāng)庫(kù)而不是1個(gè)：一個(gè)本地私有的，另一個(gè)服務(wù)端公開的。
Forking工作流的一個(gè)主要優(yōu)勢(shì)是，貢獻(xiàn)的代碼可以被集成，而不需要所有人都能push代碼到僅有的中央倉(cāng)庫(kù)中。 開發(fā)者push到自己的服務(wù)端倉(cāng)庫(kù)，而只有項(xiàng)目維護(hù)者才能push到正式倉(cāng)庫(kù)。 這樣項(xiàng)目維護(hù)者可以接受任何開發(fā)者的提交，但無(wú)需給他正式代碼庫(kù)的寫權(quán)限。
效果就是一個(gè)分布式的工作流，能為大型、自發(fā)性的團(tuán)隊(duì)（包括了不受信的第三方）提供靈活的方式來(lái)安全的協(xié)作。 也讓這個(gè)工作流成為開源項(xiàng)目的理想工作流。
2.4.1 工作方式
和其它的Git工作流一樣，Forking工作流要先有一個(gè)公開的正式倉(cāng)庫(kù)存儲(chǔ)在服務(wù)器上。 但一個(gè)新的開發(fā)者想要在項(xiàng)目上工作時(shí)，不是直接從正式倉(cāng)庫(kù)克隆，而是fork正式項(xiàng)目在服務(wù)器上創(chuàng)建一個(gè)拷貝。
這個(gè)倉(cāng)庫(kù)拷貝作為他個(gè)人公開倉(cāng)庫(kù) —— 其它開發(fā)者不允許push到這個(gè)倉(cāng)庫(kù)，但可以pull到修改（后面我們很快就會(huì)看這點(diǎn)很重要）。 在創(chuàng)建了自己服務(wù)端拷貝之后，和之前的工作流一樣，開發(fā)者執(zhí)行g(shù)it clone命令克隆倉(cāng)庫(kù)到本地機(jī)器上，作為私有的開發(fā)環(huán)境。
要提交本地修改時(shí)，push提交到自己公開倉(cāng)庫(kù)中 —— 而不是正式倉(cāng)庫(kù)中。 然后，給正式倉(cāng)庫(kù)發(fā)起一個(gè)pull request，讓項(xiàng)目維護(hù)者知道有更新已經(jīng)準(zhǔn)備好可以集成了。 對(duì)于貢獻(xiàn)的代碼，pull request也可以很方便地作為一個(gè)討論的地方。
為了集成功能到正式代碼庫(kù)，維護(hù)者pull貢獻(xiàn)者的變更到自己的本地倉(cāng)庫(kù)中，檢查變更以確保不會(huì)讓項(xiàng)目出錯(cuò)，?合并變更到自己本地的master分支， 然后pushmaster分支到服務(wù)器的正式倉(cāng)庫(kù)中。 到此，貢獻(xiàn)的提交成為了項(xiàng)目的一部分，其它的開發(fā)者應(yīng)該執(zhí)行pull操作與正式倉(cāng)庫(kù)同步自己本地倉(cāng)庫(kù)。
2.4.2 正式倉(cāng)庫(kù)
在Forking工作流中，『官方』倉(cāng)庫(kù)的叫法只是一個(gè)約定，理解這點(diǎn)很重要。 從技術(shù)上來(lái)看，各個(gè)開發(fā)者倉(cāng)庫(kù)和正式倉(cāng)庫(kù)在Git看來(lái)沒(méi)有任何區(qū)別。 事實(shí)上，讓正式倉(cāng)庫(kù)之所以正式的唯一原因是它是項(xiàng)目維護(hù)者的公開倉(cāng)庫(kù)。
2.4.3?Forking工作流的分支使用方式
所有的個(gè)人公開倉(cāng)庫(kù)實(shí)際上只是為了方便和其它的開發(fā)者共享分支。 各個(gè)開發(fā)者應(yīng)該用分支隔離各個(gè)功能，就像在功能分支工作流和Gitflow工作流一樣。 唯一的區(qū)別是這些分支被共享了。在Forking工作流中這些分支會(huì)被pull到另一個(gè)開發(fā)者的本地倉(cāng)庫(kù)中，而在功能分支工作流和Gitflow工作流中是直接被push到正式倉(cāng)庫(kù)中。
2.4.4 示例
項(xiàng)目維護(hù)者初始化正式倉(cāng)庫(kù)
和任何使用Git項(xiàng)目一樣，第一步是創(chuàng)建在服務(wù)器上一個(gè)正式倉(cāng)庫(kù)，讓所有團(tuán)隊(duì)成員都可以訪問(wèn)到。 通常這個(gè)倉(cāng)庫(kù)也會(huì)作為項(xiàng)目維護(hù)者的公開倉(cāng)庫(kù)。
公開倉(cāng)庫(kù)應(yīng)該是裸倉(cāng)庫(kù)，不管是不是正式代碼庫(kù)。 所以項(xiàng)目維護(hù)者會(huì)運(yùn)行像下面的命令來(lái)搭建正式倉(cāng)庫(kù)：
ssh user@host git init --bare /path/to/repo.gitBitbucket和Stash提供了一個(gè)方便的GUI客戶端以完成上面命令行做的事。 這個(gè)搭建中央倉(cāng)庫(kù)的過(guò)程和前面提到的工作流完全一樣。 如果有現(xiàn)存的代碼庫(kù)，維護(hù)者也要push到這個(gè)倉(cāng)庫(kù)中。
開發(fā)者fork正式倉(cāng)庫(kù)
其它所有的開發(fā)需要fork正式倉(cāng)庫(kù)。 可以用git clone命令用SSH協(xié)議連通到服務(wù)器， 拷貝倉(cāng)庫(kù)到服務(wù)器另一個(gè)位置 —— 是的，fork操作基本上就只是一個(gè)服務(wù)端的克隆。?Bitbucket和Stash上可以點(diǎn)一下按鈕就讓開發(fā)者完成倉(cāng)庫(kù)的fork操作。
這一步完成后，每個(gè)開發(fā)都在服務(wù)端有一個(gè)自己的倉(cāng)庫(kù)。和正式倉(cāng)庫(kù)一樣，這些倉(cāng)庫(kù)應(yīng)該是裸倉(cāng)庫(kù)。
開發(fā)者克隆自己fork出來(lái)的倉(cāng)庫(kù)
下一步，各個(gè)開發(fā)者要克隆自己的公開倉(cāng)庫(kù)，用熟悉的git clone命令。
在這個(gè)示例中，假定用Bitbucket托管了倉(cāng)庫(kù)。記住，如果這樣的話各個(gè)開發(fā)者需要有各自的Bitbucket賬號(hào)， 使用下面命令克隆服務(wù)端自己的倉(cāng)庫(kù)：
git clone https://user@bitbucket.org/user/repo.git相比前面介紹的工作流只用了一個(gè)origin遠(yuǎn)程別名指向中央倉(cāng)庫(kù)，Forking工作流需要2個(gè)遠(yuǎn)程別名 —— 一個(gè)指向正式倉(cāng)庫(kù)，另一個(gè)指向開發(fā)者自己的服務(wù)端倉(cāng)庫(kù)。別名的名字可以任意命名，常見的約定是使用origin作為遠(yuǎn)程克隆的倉(cāng)庫(kù)的別名 （這個(gè)別名會(huì)在運(yùn)行g(shù)it clone自動(dòng)創(chuàng)建），upstream（上游）作為正式倉(cāng)庫(kù)的別名。
git remote add upstream https://bitbucket.org/maintainer/repo需要自己用上面的命令創(chuàng)建upstream別名。這樣可以簡(jiǎn)單地保持本地倉(cāng)庫(kù)和正式倉(cāng)庫(kù)的同步更新。 注意，如果上游倉(cāng)庫(kù)需要認(rèn)證（比如不是開源的），你需要提供用戶：
git remote add upstream https://user@bitbucket.org/maintainer/repo.git這時(shí)在克隆和pull正式倉(cāng)庫(kù)時(shí)，需要提供用戶的密碼。
開發(fā)者開發(fā)自己的功能
在剛克隆的本地倉(cāng)庫(kù)中，開發(fā)者可以像其它工作流一樣的編輯代碼、提交修改和新建分支：
git checkout -b some-feature # Edit some code git commit -a -m "Add first draft of some feature"所有的修改都是私有的直到push到自己公開倉(cāng)庫(kù)中。如果正式項(xiàng)目已經(jīng)往前走了，可以用git pull命令獲得新的提交：
git pull upstream master由于開發(fā)者應(yīng)該都在專門的功能分支上工作，pull操作結(jié)果會(huì)都是快進(jìn)合并。
開發(fā)者發(fā)布自己的功能
一旦開發(fā)者準(zhǔn)備好了分享新功能，需要做二件事。 首先，通過(guò)push他的貢獻(xiàn)代碼到自己的公開倉(cāng)庫(kù)中，讓其它的開發(fā)者都可以訪問(wèn)到。 他的origin遠(yuǎn)程別名應(yīng)該已經(jīng)有了，所以要做的就是：
git push origin feature-branch這里和之前的工作流的差異是，origin遠(yuǎn)程別名指向開發(fā)者自己的服務(wù)端倉(cāng)庫(kù)，而不是正式倉(cāng)庫(kù)。
第二件事，開發(fā)者要通知項(xiàng)目維護(hù)者，想要合并他的新功能到正式庫(kù)中。?Bitbucket和Stash提供了Pull Request按鈕，彈出表單讓你指定哪個(gè)分支要合并到正式倉(cāng)庫(kù)。 一般你會(huì)想集成你的功能分支到上游遠(yuǎn)程倉(cāng)庫(kù)的master分支中。
項(xiàng)目維護(hù)者集成開發(fā)者的功能
當(dāng)項(xiàng)目維護(hù)者收到pull request，他要做的是決定是否集成它到正式代碼庫(kù)中。有二種方式來(lái)做：
第一種做法更簡(jiǎn)單，維護(hù)者可以在GUI中查看變更的差異，做評(píng)注和執(zhí)行合并。 但如果出現(xiàn)了合并沖突，需要第二種做法來(lái)解決。這種情況下，維護(hù)者需要從開發(fā)者的服務(wù)端倉(cāng)庫(kù)中fetch功能分支， 合并到他本地的master分支，解決沖突：
git fetch https://bitbucket.org/user/repo feature-branch # 查看變更 git checkout master git merge FETCH_HEAD變更集成到本地的master分支后，維護(hù)者要push變更到服務(wù)器上的正式倉(cāng)庫(kù)，這樣其它的開發(fā)者都能訪問(wèn)到：
git push origin master注意，維護(hù)者的origin是指向他自己公開倉(cāng)庫(kù)的，即是項(xiàng)目的正式代碼庫(kù)。到此，開發(fā)者的貢獻(xiàn)完全集成到了項(xiàng)目中。
開發(fā)者和正式倉(cāng)庫(kù)做同步
由于正式代碼庫(kù)往前走了，其它的開發(fā)需要和正式倉(cāng)庫(kù)做同步：
git pull upstream master如果你之前是使用SVN，Forking工作流可能看起來(lái)像是一個(gè)激進(jìn)的范式切換（paradigm shift）。 但不要害怕，這個(gè)工作流實(shí)際上就是在功能分支工作流之上引入另一個(gè)抽象層。 不是直接通過(guò)單個(gè)中央倉(cāng)庫(kù)來(lái)分享分支，而是把貢獻(xiàn)代碼發(fā)布到開發(fā)者自己的服務(wù)端倉(cāng)庫(kù)中。
示例中解釋了，一個(gè)貢獻(xiàn)如何從一個(gè)開發(fā)者流到正式的master分支中，但同樣的方法可以把貢獻(xiàn)集成到任一個(gè)倉(cāng)庫(kù)中。 比如，如果團(tuán)隊(duì)的幾個(gè)人協(xié)作實(shí)現(xiàn)一個(gè)功能，可以在開發(fā)之間用相同的方法分享變更，完全不涉及正式倉(cāng)庫(kù)。
這使得Forking工作流對(duì)于松散組織的團(tuán)隊(duì)來(lái)說(shuō)是個(gè)非常強(qiáng)大的工具。任一開發(fā)者可以方便地和另一開發(fā)者分享變更，任何分支都能有效地合并到正式代碼庫(kù)中。
2.5?Pull Requests
Pull requests是Bitbucket提供的讓開發(fā)者更方便地進(jìn)行協(xié)作的功能，提供了友好的Web界面可以在提議的修改合并到正式項(xiàng)目之前對(duì)修改進(jìn)行討論。
開發(fā)者向團(tuán)隊(duì)成員通知功能開發(fā)已經(jīng)完成，Pull Requests是最簡(jiǎn)單的用法。 開發(fā)者完成功能開發(fā)后，通過(guò)Bitbucket賬號(hào)發(fā)起一個(gè)Pull Request。 這樣讓涉及這個(gè)功能的所有人知道要去做Code Review和合并到master分支。
但是，Pull Request遠(yuǎn)不止一個(gè)簡(jiǎn)單的通知，而是為討論提交的功能的一個(gè)專門論壇。 如果變更有任何問(wèn)題，團(tuán)隊(duì)成員反饋在Pull Request中，甚至push新的提交微調(diào)功能。 所有的這些活動(dòng)都直接跟蹤在Pull Request中。
相比其它的協(xié)作模型，這種分享提交的形式有助于打造一個(gè)更流暢的工作流。?SVN和Git都能通過(guò)一個(gè)簡(jiǎn)單的腳本收到通知郵件；但是，討論變更時(shí)，開發(fā)者通常只能去回復(fù)郵件。 這樣做會(huì)變得雜亂，尤其還要涉及后面的幾個(gè)提交時(shí)。?Pull Requests把所有相關(guān)功能整合到一個(gè)和Bitbucket倉(cāng)庫(kù)界面集成的用戶友好Web界面中。
2.5.1 解析Pull Request
當(dāng)要發(fā)起一個(gè)Pull Request，你所要做的就是請(qǐng)求（Request）另一個(gè)開發(fā)者（比如項(xiàng)目的維護(hù)者） 來(lái)pull你倉(cāng)庫(kù)中一個(gè)分支到他的倉(cāng)庫(kù)中。這意味著你要提供4個(gè)信息以發(fā)起Pull Request： 源倉(cāng)庫(kù)、源分支、目的倉(cāng)庫(kù)、目的分支。
這幾值多數(shù)Bitbucket都會(huì)設(shè)置上合適的缺省值。但取決你用的協(xié)作工作流，你的團(tuán)隊(duì)可能會(huì)要指定不同的值。 上圖顯示了一個(gè)Pull Request請(qǐng)求合并一個(gè)功能分支到正式的master分支上，但可以有多種不同的Pull Request用法。
2.5.2 工作方式
Pull Request可以和功能分支工作流、Gitflow工作流或Forking工作流一起使用。 但一個(gè)Pull Request要求要么分支不同要么倉(cāng)庫(kù)不同，所以不能用于集中式工作流。 在不同的工作流中使用Pull Request會(huì)有一些不同，但基本的過(guò)程是這樣的：
本文后面內(nèi)容說(shuō)明，Pull Request在不同協(xié)作工作流中如何應(yīng)用。
2.5.3 在功能分支工作流中使用Pull Request
功能分支工作流用一個(gè)共享的Bitbucket倉(cāng)庫(kù)來(lái)管理協(xié)作，開發(fā)者在專門的分支上開發(fā)功能。 但不是立即合并到master分支上，而是在合并到主代碼庫(kù)之前開發(fā)者應(yīng)該開一個(gè)Pull Request發(fā)起功能的討論。
功能分支工作流只有一個(gè)公開的倉(cāng)庫(kù)，所以Pull Request的目的倉(cāng)庫(kù)和源倉(cāng)庫(kù)總是同一個(gè)。 通常開發(fā)者會(huì)指定他的功能分支作為源分支，master分支作為目的分支。
收到Pull Request后，項(xiàng)目維護(hù)者要決定如何做。如果功能沒(méi)問(wèn)題，就簡(jiǎn)單地合并到master分支，關(guān)閉Pull Request。 但如果提交的變更有問(wèn)題，他可以在Pull Request中反饋。之后新加的提交也會(huì)評(píng)論之后接著顯示出來(lái)。
在功能還沒(méi)有完全開發(fā)完的時(shí)候，也可能發(fā)起一個(gè)Pull Request。 比如開發(fā)者在實(shí)現(xiàn)某個(gè)需求時(shí)碰到了麻煩，他可以發(fā)一個(gè)包含正在進(jìn)行中工作的Pull Request。 其它的開發(fā)者可以在Pull Request提供建議，或者甚至直接添加提交來(lái)解決問(wèn)題。
2.5.4 在Gitflow工作流中使用Pull Request
Gitflow工作流和功能分支工作流類似，但圍繞項(xiàng)目發(fā)布定義一個(gè)嚴(yán)格的分支模型。 在Gitflow工作流中使用Pull Request讓開發(fā)者在發(fā)布分支或是維護(hù)分支上工作時(shí)， 可以有個(gè)方便的地方對(duì)關(guān)于發(fā)布分支或是維護(hù)分支的問(wèn)題進(jìn)行交流。
Gitflow工作流中Pull Request的使用過(guò)程和上一節(jié)中完全一致： 當(dāng)一個(gè)功能、發(fā)布或是熱修復(fù)分支需要Review時(shí)，開發(fā)者簡(jiǎn)單發(fā)起一個(gè)Pull Request， 團(tuán)隊(duì)的其它成員會(huì)通過(guò)Bitbucket收到通知。
新功能一般合并到develop分支，而發(fā)布和熱修復(fù)則要同時(shí)合并到develop分支和master分支上。?Pull Request可能用做所有合并的正式管理。
2.5.5 在Forking工作流中使用Pull Request
在Forking工作流中，開發(fā)者push完成的功能到他自己的倉(cāng)庫(kù)中，而不是共享倉(cāng)庫(kù)。 然后，他發(fā)起一個(gè)Pull Request，讓項(xiàng)目維護(hù)者知道他的功能已經(jīng)可以Review了。
在這個(gè)工作流，Pull Request的通知功能非常有用， 因?yàn)轫?xiàng)目維護(hù)者不可能知道其它開發(fā)者在他們自己的倉(cāng)庫(kù)添加了提交。
由于各個(gè)開發(fā)有自己的公開倉(cāng)庫(kù)，Pull Request的源倉(cāng)庫(kù)和目標(biāo)倉(cāng)庫(kù)不是同一個(gè)。 源倉(cāng)庫(kù)是開發(fā)者的公開倉(cāng)庫(kù)，源分支是包含了修改的分支。 如果開發(fā)者要合并修改到正式代碼庫(kù)中，那么目標(biāo)倉(cāng)庫(kù)是正式倉(cāng)庫(kù)，目標(biāo)分支是master分支。
Pull Request也可以用于正式項(xiàng)目之外的其它開發(fā)者之間的協(xié)作。 比如，如果一個(gè)開發(fā)者和一個(gè)團(tuán)隊(duì)成員一起開發(fā)一個(gè)功能，他們可以發(fā)起一個(gè)Pull Request， 用團(tuán)隊(duì)成員的Bitbucket倉(cāng)庫(kù)作為目標(biāo)，而不是正式項(xiàng)目的倉(cāng)庫(kù)。 然后使用相同的功能分支作為源和目標(biāo)分支。
2個(gè)開發(fā)者之間可以在Pull Request中討論和開發(fā)功能。 完成開發(fā)后，他們可以發(fā)起另一個(gè)Pull Request，請(qǐng)求合并功能到正式的master分支。 在Forking工作流中，這樣的靈活性讓Pull Request成為一個(gè)強(qiáng)有力的協(xié)作工具。
2.5.6 示例
下面的示例演示了Pull Request如何在在Forking工作流中使用。 也同樣適用于小團(tuán)隊(duì)的開發(fā)協(xié)作和第三方開發(fā)者向開源項(xiàng)目的貢獻(xiàn)。
在示例中，小紅是個(gè)開發(fā)，小明是項(xiàng)目維護(hù)者。他們各自有一個(gè)公開的Bitbucket倉(cāng)庫(kù)，而小明的倉(cāng)庫(kù)包含了正式工程。
小紅fork正式項(xiàng)目
小紅先要fork小明的Bitbucket倉(cāng)庫(kù)，開始項(xiàng)目的開發(fā)。她登陸B(tài)itbucket，瀏覽到小明的倉(cāng)庫(kù)頁(yè)面， 點(diǎn)Fork按鈕。
然后為fork出來(lái)的倉(cāng)庫(kù)填寫名字和描述，這樣小紅就有了服務(wù)端的項(xiàng)目拷貝了。
小紅克隆她的Bitbucket倉(cāng)庫(kù)
下一步，小紅克隆自己剛才fork出來(lái)的Bitbucket倉(cāng)庫(kù)，以在本機(jī)上準(zhǔn)備出工作拷貝。命令如下：
git clone https://user@bitbucket.org/user/repo.git請(qǐng)記住，git clone會(huì)自動(dòng)創(chuàng)建origin遠(yuǎn)程別名，是指向小紅fork出來(lái)的倉(cāng)庫(kù)。
小紅開發(fā)新功能
在開始改代碼前，小紅要為新功能先新建一個(gè)新分支。她會(huì)用這個(gè)分支作為Pull Request的源分支。
git checkout -b some-feature # 編輯代碼 git commit -a -m "Add first draft of some feature"在新功能分支上，小紅按需要添加提交。甚至如果小紅覺(jué)得功能分支上的提交歷史太亂了，她可以用交互式rebase來(lái)刪除或壓制提交。 對(duì)于大型項(xiàng)目，整理功能分支的歷史可以讓項(xiàng)目維護(hù)者更容易看出在Pull Request中做了什么內(nèi)容。
小紅push功能到她的Bitbucket倉(cāng)庫(kù)中
小紅完成了功能后，push功能到她自己的Bitbucket倉(cāng)庫(kù)中（不是正式倉(cāng)庫(kù)），用下面簡(jiǎn)單的命令：
git push origin some-branch這時(shí)她的變更可以讓項(xiàng)目維護(hù)者看到了（或者任何想要看的協(xié)作者）。
小紅發(fā)起Pull Request
Bitbucket上有了她的功能分支后，小紅可以用她的Bitbucket賬號(hào)瀏覽到她的fork出來(lái)的倉(cāng)庫(kù)頁(yè)面， 點(diǎn)右上角的【Pull Request】按鈕，發(fā)起一個(gè)Pull Request。 彈出的表單自動(dòng)設(shè)置小紅的倉(cāng)庫(kù)為源倉(cāng)庫(kù)，詢問(wèn)小紅以指定源分支、目標(biāo)倉(cāng)庫(kù)和目標(biāo)分支。
小紅想要合并功能到正式倉(cāng)庫(kù)，所以源分支是她的功能分支，目標(biāo)倉(cāng)庫(kù)是小明的公開倉(cāng)庫(kù)， 而目標(biāo)分支是master分支。另外，小紅需要提供Pull Request的標(biāo)題和描述信息。 如果需要小明以外的人審核批準(zhǔn)代碼，她可以把這些人填在【Reviewers】文本框中。
創(chuàng)建好了Pull Request，通知會(huì)通過(guò)Bitbucket系統(tǒng)消息或郵件（可選）發(fā)給小明。
小明review?Pull Request
在小明的Bitbucket倉(cāng)庫(kù)頁(yè)面的【Pull Request】Tab可以看到所有人發(fā)起的Pull Request。 點(diǎn)擊小紅的Pull Request會(huì)顯示出Pull Request的描述、功能的提交歷史和每個(gè)變更的差異（diff）。
如果小明想要合并到項(xiàng)目中，只要點(diǎn)一下【Merge】按鈕，就可以同意Pull Request并合并到master分支。
但如果像這個(gè)示例中一樣小明發(fā)現(xiàn)了在小紅的代碼中的一個(gè)小Bug，要小紅在合并前修復(fù)。 小明可以在整個(gè)Pull Request上加上評(píng)注，或是選擇歷史中的某個(gè)提交加上評(píng)注。
小紅補(bǔ)加提交
如果小紅對(duì)反饋有任何疑問(wèn)，可以在Pull Request中響應(yīng)，把Pull Request當(dāng)作是她功能討論的論壇。
小紅在她的功能分支新加提交以解決代碼問(wèn)題，并push到她的Bitbucket倉(cāng)庫(kù)中，就像前一輪中的做法一樣。 這些提交會(huì)進(jìn)入的Pull Request，小明在原來(lái)的評(píng)注旁邊可以再次review變更。
小明接受Pull Request
最終，小明接受變更，合并功能分支到Master分支，并關(guān)閉Pull Request。 至此，功能集成到項(xiàng)目中，其它的項(xiàng)目開發(fā)者可以用標(biāo)準(zhǔn)的git pull命令pull這些變更到自己的本地倉(cāng)庫(kù)中。
到了這里，你應(yīng)該有了所有需要的工具來(lái)集成Pull Request到你自己的工作流。 請(qǐng)記住，Pull Request并不是為了替代任何?基于Git的協(xié)作工作流， 而是它們的一個(gè)便利的補(bǔ)充，讓團(tuán)隊(duì)成員間的協(xié)作更輕松方便。
三、企業(yè)日常開發(fā)模式探索
在看這部分前，請(qǐng)先回顧閱讀業(yè)界認(rèn)可的成功的 Git Branch Work Flow 模型?A Successful Git Branching Model?，了解日常開發(fā)中的場(chǎng)景，有助于熟悉下面的使用過(guò)程。
在企業(yè)開發(fā)中，使用 Git 作為版本控制軟件最看重的還是結(jié)合公司自己搭建的?Gitlab，將 Code Review 加入打包部署持續(xù)集成的流程中，這樣，代碼開發(fā)完成，提交測(cè)試前，便可以對(duì)開發(fā)人員提交的代碼進(jìn)行 Review，發(fā)現(xiàn)潛在的問(wèn)題，及時(shí)指導(dǎo)，對(duì)于新人來(lái)講，也能更快更好的學(xué)習(xí)。
解決的需求場(chǎng)景如下：
- 能支持日常迭代開發(fā)、緊急線上bug修復(fù)、多功能并行開發(fā)
- 大概50人左右的團(tuán)隊(duì)，平日迭代項(xiàng)目較多，且周期短（1~2周一個(gè)迭代）
- 能夠通過(guò)tag重建整個(gè)系統(tǒng)
- 支持code review
- 所有上線的代碼必須都是經(jīng)過(guò)測(cè)試保證，且能自動(dòng)同步到下一次的迭代中
- 能和公司的項(xiàng)目管理/持續(xù)集成系統(tǒng)整合
上圖就是 xirong 團(tuán)隊(duì)在日常開發(fā)中總結(jié)出來(lái)的適合企業(yè)開發(fā)的模式，下面進(jìn)行簡(jiǎn)單的介紹，方便大家學(xué)習(xí)了解，歡迎提交 Issue 進(jìn)行討論。（本模式適合敏捷開發(fā)流程，小迭代上線，傳統(tǒng)的瀑布開發(fā)模型并沒(méi)有進(jìn)行測(cè)試）
這樣經(jīng)過(guò)上面的1-5步驟，企業(yè)日常迭代開發(fā)中的代碼版本控制基本上就 Ok 了，有問(wèn)題歡迎 Issue 討論。
2016-11月 更新?Git 分支開發(fā)部署模型?的一些使用原則如下:
- master：master永遠(yuǎn)是線上代碼，最穩(wěn)定的分支，存放的是隨時(shí)可供在生產(chǎn)環(huán)境中部署的代碼，當(dāng)開發(fā)活動(dòng)告一段落，產(chǎn)生了一份新的可供部署的代碼時(shí)，發(fā)布成功之后，代碼才會(huì)由 aone2 提交到 master，master 分支上的代碼會(huì)被更新。應(yīng)用上 aone2 后禁掉所有人的 master的寫權(quán)限
- develop：保存當(dāng)前最新開發(fā)成果的分支。通常這個(gè)分支上的代碼也是可進(jìn)行每日夜間發(fā)布的代碼，只對(duì)開發(fā)負(fù)責(zé)人開放develop權(quán)限。
- feature: 功能特性分支，每個(gè)功能特性一個(gè) feature/ 分支，開發(fā)完成自測(cè)通過(guò)后合并入 develop 分支。可以從 master 或者develop 中拉出來(lái)。
- hotfix: 緊急bug分支修復(fù)分支。修復(fù)上線后，可以直接合并入master。
Git-Develop 分支模式是基于 Git 代碼庫(kù)設(shè)計(jì)的一種需要嚴(yán)格控制發(fā)布質(zhì)量和發(fā)布節(jié)奏的開發(fā)模式。develop 作為固定的持續(xù)集成和發(fā)布分支，并且分支上的代碼必須經(jīng)過(guò) CodeReview 后才可以提交到 Develop 分支。它的基本流程如下：
- 每一個(gè)需求/變更都單獨(dú)從Master上創(chuàng)建一條Branch分支；
- 用戶在這個(gè)Branch分支上進(jìn)行Codeing活動(dòng)；
- 代碼達(dá)到發(fā)布準(zhǔn)入條件后aone上提交Codereview，Codereview通過(guò)后代碼自動(dòng)合并到Develop分支；
- 待所有計(jì)劃發(fā)布的變更分支代碼都合并到Develop后，系統(tǒng)再 rebase master 代碼到Develop 分支，然后自行構(gòu)建，打包，部署等動(dòng)作。
- 應(yīng)用發(fā)布成功后Aone會(huì)基于Develop分支的發(fā)布版本打一個(gè)“當(dāng)前線上版本Tag”基線；
- 應(yīng)用發(fā)布成功后Aone會(huì)自動(dòng)把Develop分支的發(fā)布版本合并回master；
轉(zhuǎn)載于:https://my.oschina.net/u/3371661/blog/3044490
《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀總結(jié)
以上是生活随笔為你收集整理的git的操作说明超详细的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： .NET混淆器 Dotfuscator使
- 下一篇： Linux 分析工具--性能