Git的工作方式

分為集中式工作流、功能分支工作流、Gitflow工作流和Forking，其中集中式工作流和功能分支工作流是已經(jīng)使用過(guò)的，Gitflow和Forking兩種工作流暫時(shí)沒(méi)有使用過(guò)。

集中式工作流

一個(gè)遠(yuǎn)程倉(cāng)庫(kù)，一個(gè)主分支master，團(tuán)隊(duì)每個(gè)成員都有一個(gè)本地倉(cāng)庫(kù)，在本地倉(cāng)庫(kù)中進(jìn)行代碼的編輯、暫存和提交工作：

git add <some file> 或 git add .>
//`some file`代表要暫存的文件，`.`代表工作目錄下的所有文件
gie commit -m "一些描述"
//提交文，描述指的是本次提交修改了什么功能或者修改了什么bug，方便以后的查看
git push -u origin master
//-u選項(xiàng)設(shè)置本地分支去跟蹤遠(yuǎn)程對(duì)應(yīng)的分支。設(shè)置好跟蹤的分支后，就可以使用git push命令省去指定推送分支的參數(shù)
//發(fā)布本地倉(cāng)庫(kù)到遠(yuǎn)程的中央倉(cāng)庫(kù)中，origin是遠(yuǎn)程倉(cāng)庫(kù)名，master是參數(shù)告訴Git的分支，master代表主分支，當(dāng)然分支可以不是主分支

注意:在一種情況下push命令會(huì)出錯(cuò)，即如果小明第一次發(fā)布代碼到遠(yuǎn)程倉(cāng)庫(kù)，此時(shí)小紅在 本地開發(fā)自己的功能，那么在小紅push自己的本地庫(kù)到遠(yuǎn)程的時(shí)候會(huì)報(bào)錯(cuò)，原因是小紅的本地庫(kù)和遠(yuǎn)程庫(kù)有分歧，需要先pull遠(yuǎn)程庫(kù)到本地，與本地庫(kù)合并之后再push到遠(yuǎn)程庫(kù)。

功能分支工作流

在集中式工作流的基礎(chǔ)上，為各個(gè)新功能分配一個(gè)專門的分支來(lái)開發(fā)，即在master主分支外在創(chuàng)建一個(gè)分支，程序員開發(fā)的新功能全部push到此分支上，等到功能成熟的時(shí)候再把此分支合并到主分支master上

git checkout -b newbranch master
//checkout代表創(chuàng)建切換帶新分支newbranch
//-b代表如果新分支不存在則會(huì)創(chuàng)建一個(gè)新分支
//最后的master代表新分支是基于主分支創(chuàng)建的

新分支創(chuàng)建之后，對(duì)其的編輯、暫存和提交工作與之前一樣，對(duì)其push的命令變?yōu)?/p>

git push origin newbranch

等到新功能完善之后，通過(guò)以下命令：

git checkout mastergit pullgit pull origin newbranchgit push

首先git checkout master切換到主分支，然后執(zhí)行g(shù)it pull把本地倉(cāng)庫(kù)的主分支上傳到遠(yuǎn)程庫(kù)，再執(zhí)行g(shù)it pull origin newbranch保證合并newbranch分支和已經(jīng)和遠(yuǎn)程一致的本地master分支，你可以使用簡(jiǎn)單git merge newbranch命令，但前面的命令可以保證總是最新的新功能分支。 最后把更新的master分支重新push到遠(yuǎn)程庫(kù)。

Gitflow工作流

Gitflow工作流沒(méi)有用超出功能分支工作流的概念和命令，而是為不同的分支分配一個(gè)很明確的角色，并定義分支之間如何和什么時(shí)候進(jìn)行交互。
除了有master主分支（用于存儲(chǔ)正式發(fā)布的歷史）外，還有一個(gè)作為功能集成分支的develop分支。當(dāng)初始化完成后，某個(gè)程序員想要開發(fā)一個(gè)性能，并不是直接從master分支上拉出新分支，而是使用develop分支作為父分支，當(dāng)新功能完成后，再合并會(huì)父分支，新功能的提交并不與master分支直接交互。

一旦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分支。

維護(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ā)布。

工作流程

為master分支配套一個(gè)develop分支

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ā)都有了這些歷史分支的本地拷貝。
小紅和小明開團(tuán)隊(duì)成員始各自的功能開發(fā)。他們需要為各自的功能創(chuàng)建相應(yīng)的分支。新分支不是基于master分支，而是應(yīng)該基于develop分支：

git checkout -b some-feature develop

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

git status
git add <some-file>
git commit

添加了提交后，功能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分支。 沖突解決方法和集中式工作流一樣。

Forking工作流

分布式工作流，充分利用了Git在分支和克隆上的優(yōu)勢(shì)，既可以管理大團(tuán)隊(duì)的開發(fā)者（developer）和接受不信任貢獻(xiàn)者（contributor）的提交。這種工作流使得每個(gè)開發(fā)者都有一個(gè)服務(wù)端倉(cāng)庫(kù)（此倉(cāng)庫(kù)只有自己可以push，但是所有人都可以pull修改），每個(gè)程序員都push代碼到自己的服務(wù)端倉(cāng)庫(kù)，但不能push到正式倉(cāng)庫(kù)，只有項(xiàng)目維護(hù)者才能push到正式倉(cāng)庫(kù)，這樣項(xiàng)目維護(hù)者可以接受任何開發(fā)者的提交，但無(wú)需給他正式代碼庫(kù)的寫權(quán)限。
這種工作流適合網(wǎng)上開源社區(qū)的開源項(xiàng)目，大家統(tǒng)一對(duì)項(xiàng)目做貢獻(xiàn)，但是有一個(gè)人或一個(gè)團(tuán)隊(duì)作為開發(fā)者來(lái)管理項(xiàng)目，所有的貢獻(xiàn)者的代碼由開發(fā)者審核，其功能完善之后再由開發(fā)者push到正式倉(cāng)庫(kù)中。

Pull Request

Pull Request是一個(gè)為討論提交功能的專門論壇，是一個(gè)友好的web界面（在個(gè)人github項(xiàng)目中也有這樣一個(gè)選項(xiàng)），大家在其中做一些Code Review的工作，把結(jié)果反饋到Pull Request中，還可以在其中push新的提交微調(diào)功能，等到討論結(jié)束后醒目維護(hù)者合并所有的功能到官方倉(cāng)庫(kù)中，關(guān)閉Pull Request。

發(fā)起一個(gè)Pull Request，就是要請(qǐng)求另一個(gè)開發(fā)者來(lái)pull自己倉(cāng)庫(kù)的一個(gè)分支到它的倉(cāng)庫(kù)中，因此需要提供四個(gè)信息：源倉(cāng)庫(kù)、源分支、目的倉(cāng)庫(kù)、目的分支。

Pull Request可以用于上述除了集中式工作流的其他三種工作流，因?yàn)槠湟笠捶种Р煌磦}(cāng)庫(kù)不同，而集中式工作流只有一個(gè)倉(cāng)庫(kù)，一個(gè)master分支。

例：

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

功能分支工作流只有一個(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)題。

參考：http://shouce.jb51.net/gitbook/Distributed-Git/Distributed-Workflows.html

以上就是Git工作流模式及命令的使用講解的詳細(xì)內(nèi)容，更多關(guān)于Git的工作流模式命令使用的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論