個人在學習git工作流的過程中,從原有的 SVN 模式很難完全理解git的協作模式,直到有一天我看到了下面的文章,好多遺留在心中的困惑迎刃而解,于是我將這部分資料進行整理放到了github上,歡迎star查看最新更新內容, //github.com/xirong/my-git/blob/master/git-workflow-tutorial.md

  • 我們以使用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


一、譯序

工作流其實不是一個初級主題,背后的本質問題其實是有效的項目流程管理和高效的開發協同約定,不僅是Git或SVN等VCSSCM工具的使用。

這篇指南以大家在SVN中已經廣為熟悉使用的集中式工作流作為起點,循序漸進地演進到其它高效的分布式工作流,還介紹了如何配合使用便利的Pull Request功能,體系地講解了各種工作流的應用。

行文中實踐原則和操作示例并重,對于Git的資深玩家可以梳理思考提升,而新接觸的同學,也可以跟著step-by-step操作來操練學習并在實際工作中上手使用。

關于Git工作流主題,網上體系的中文資料不多,主要是零散的操作說明,希望這篇文章能讓你更深入理解并在工作中靈活有效地使用起來。

PS

文中Pull Request的介紹用的是Bitbucket代碼托管服務,由于和GitHub基本一樣,如果你用的是GitHub(我自己也主要使用GitHub托管代碼),不影響理解和操作。

PPS

本指南循序漸進地講解工作流,如果Git用的不多,可以從前面的講的工作流開始操練。操作過程去感受指南的講解:解決什么問題、如何解決問題,這樣理解就深了,也方便活用。

Gitflow工作流是經典模型,體現了工作流的經驗和精髓。隨著項目過程復雜化,會感受到這個工作流中深思熟慮和威力!

Forking工作流是協作的(GitHub風格)可以先看看Github的Help:Fork A RepoUsing pull requests 。照著操作,給一個Github項目貢獻你的提交,有操作經驗再看指南容易意會。指南中給了自己實現Fork的方法:Fork就是服務端的克隆。在指南的操練中使用代碼托管服務(如GitHub、Bitbucket),可以點一下按鈕就讓開發者完成倉庫的fork操作。

:see_no_evil: 自己理解粗淺,翻譯中不足和不對之處,歡迎建議(提交Issue)和指正(Fork后提交代碼)!

二、Git工作流指南

:point_right: 工作流有各式各樣的用法,但也正因此使得在實際工作中如何上手使用變得很頭大。這篇指南通過總覽公司團隊中最常用的幾種Git工作流讓大家可以上手使用。

在閱讀的過程中請記住,本文中的幾種工作流是作為方案指導而不是條例規定。在展示了各種工作流可能的用法后,你可以從不同的工作流中挑選或揉合出一個滿足你自己需求的工作流。

Git Workflows

2.1 集中式工作流

如果你的開發團隊成員已經很熟悉Subversion,集中式工作流讓你無需去適應一個全新流程就可以體驗Git帶來的收益。這個工作流也可以作為向更Git風格工作流遷移的友好過渡。
Git Workflows: SVN-style

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

但使用Git加強開發的工作流,Git有相比SVN的幾個優勢。
首先,每個開發可以有屬于自己的整個工程的本地拷貝。隔離的環境讓各個開發者的工作和項目的其他部分修改獨立開來 ——
即自由地提交到自己的本地倉庫,先完全忽略上游的開發,直到方便的時候再把修改反饋上去。

其次,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自己提交到中央庫提交歷史之上。
這樣做的意思是在說,『我要把自己的修改加到別人已經完成的修改上?!蛔罱K的結果是一個完美的線性歷史,就像以前的SVN的工作流中一樣。

如果本地修改和上游提交有沖突,Git會暫停rebase過程,給你手動解決沖突的機會。Git解決合并沖突,用和生成提交一樣的git statusgit add命令,很一致方便。還有一點,如果解決沖突時遇到麻煩,Git可以很簡單中止整個rebase操作,重來一次(或者讓別人來幫助解決)。

2.1.3 示例

讓我們一起逐步分解來看看一個常見的小團隊如何用這個工作流來協作的。有兩個開發者小明和小紅,看他們是如何開發自己的功能并提交到中央倉庫上的。

有人先初始化好中央倉庫

第一步,有人在服務器上創建好中央倉庫。如果是新項目,你可以初始化一個空倉庫;否則你要導入已有的Git或SVN倉庫。

中央倉庫應該是個裸倉庫(bare repository),即沒有工作目錄(working directory)的倉庫??梢杂孟旅娴拿顒摻ǎ?

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

確保寫上有效的user(SSH的用戶名),host(服務器的域名或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

一旦你玩轉了集中式工作流,在開發過程中可以很簡單地加上功能分支,用來鼓勵開發者之間協作和簡化交流。

功能分支工作流背后的核心思路是所有的功能開發應該在一個專門的分支,而不是在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.2Pull 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分支到中央倉庫。

倉庫管理的產品解決方案像BitbucketStash,可以良好地支持Pull Requests??梢钥纯碨tash的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

這條命令pushmarys-feature分支到中央倉庫(origin),-u選項設置本地分支去跟蹤遠程對應的分支。
設置好跟蹤的分支后,小紅就可以使用git push命令省去指定推送分支的參數。

小紅完成功能開發

小紅吃完午飯回來,完成整個功能的開發。在合并到master之前,
她發起一個Pull Request讓團隊的其它人知道功能已經完成。但首先,她要確認中央倉庫中已經有她最近的提交:

git push

然后,在她的GitGUI客戶端中發起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)的合并。

一些GUI客戶端可以只要點一下『接受』按鈕執行好上面的命令來自動化Pull Request接受過程。
如果你的不能這樣,至少在功能合并到master分支后能自動關閉Pull Request。

與此同時,小明在做和小紅一樣的事

當小紅和小黑在marys-feature上工作并討論她的Pull Request的時候,小明在自己的功能分支上做完全一樣的事。

通過隔離功能到獨立的分支上,每個人都可以自主的工作,當然必要的時候在開發者之間分享變更還是比較繁瑣的。

到了這里,但愿你發現了功能分支可以很直接地在集中式工作流的僅有的master分支上完成多功能的開發。
另外,功能分支還使用了Pull Request,使得可以在你的版本控制GUI客戶端中討論某個提交。

功能分支工作流是開發項目異常靈活的方式。問題是,有時候太靈活了。對于大型團隊,常常需要給不同分支分配一個更具體的角色。
Gitflow工作流是管理功能開發、發布準備和維護的常用模式。


2.3Gitflow工作流

Gitflow工作流通過為功能開發、發布準備和維護分配獨立的分支,讓發布迭代過程更流暢。嚴格的分支模型也為大型項目提供了一些非常必要的結構。

Git Workflows: Gitflow Cycle

這節介紹的Gitflow工作流借鑒自在nvieVincent 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修復、文檔生成和其它?%9

国产无遮挡无码视频在线观看