Git的工作流有哪些

本篇內(nèi)容主要講解“Git的工作流有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“Git的工作流有哪些”吧!

在講 Git Flow 之前，我們先講講別的東西

• 什么是版本？
  版是指印刷時(shí)的版，本就是印刷出來的書本；版本是一種稱謂，用于描述同一事物的相互之間有差異的各種形式、狀態(tài)或內(nèi)容。
  換言之，任何事物只要有差異化都會(huì)涉及到版本這個(gè)概念，但是，我們這里說的版本，包括后面聊到的東西，都應(yīng)該是一些有意義的版本，舉個(gè)例子，小明 1 月 1 日 至 1 月 31 日 每天都在改一份策劃書，2 月 1 號(hào)小明的甲方說還是上一個(gè)版本好，此時(shí)對(duì)于小明來說，上一個(gè)版本是什么？也許是最近一次小明發(fā)給甲方的一個(gè)方案，也許是上一個(gè)甲方說還可以的方案，小明可能已經(jīng)不記得具體是幾號(hào)改完給甲方的方案了。

• 常見的版本控制有哪些？
  copy 文件以命名區(qū)分的方式、本編輯器的撤回/前進(jìn)功能、使用專業(yè)工具如 svn、git 等等都屬于版本控制的范疇，不同的版本控制有不同的用途，比如文本編輯器的撤回，可以輕松撤銷本次修改，比如 copy 文件，可以讓新舊文件同時(shí)存在，方便對(duì)比，但這些方式太過簡(jiǎn)單了，而且中間過程都是一些臨時(shí)性的東西，不足以作為一個(gè)修改歷史參考或者完整版本來看待，為此，還需要一些專業(yè)工具，如 集中式版本管理系統(tǒng) SVN、CVS，分布式版本管理系統(tǒng) BitKeeper、Git 等。

• Git 開發(fā)背景

  同生活中的許多偉大事物一樣，Git 誕生于一個(gè)極富紛爭(zhēng)大舉創(chuàng)新的年代。 Linux 內(nèi)核開源項(xiàng)目有著為數(shù)眾多的參與者。 絕大多數(shù)的 Linux 內(nèi)核維護(hù)工作都花在了提交補(bǔ)丁和保存歸檔的繁瑣事務(wù)上（1991－2002年間）。 到 2002 年，整個(gè)項(xiàng)目組開始啟用一個(gè)專有的分布式版本控制系統(tǒng) BitKeeper 來管理和維護(hù)代碼。
  到了 2005 年，開發(fā) BitKeeper 的商業(yè)公司同 Linux 內(nèi)核開源社區(qū)的合作關(guān)系結(jié)束，他們收回了 Linux 內(nèi)核社區(qū)免費(fèi)使用 BitKeeper 的權(quán)力。 這就迫使 Linux 開源社區(qū)（特別是 Linux 的締造者 Linus Torvalds）基于使用 BitKeeper 時(shí)的經(jīng)驗(yàn)教訓(xùn)，開發(fā)出自己的版本系統(tǒng)。 他們對(duì)新的系統(tǒng)制訂了若干目標(biāo)：

• 速度

• 簡(jiǎn)單的設(shè)計(jì)

• 對(duì)非線性開發(fā)模式的強(qiáng)力支持（允許成千上萬個(gè)并行開發(fā)的分支）

• 完全分布式

• 有能力高效管理類似 Linux 內(nèi)核一樣的超大規(guī)模項(xiàng)目（速度和數(shù)據(jù)量） 自誕生于 2005 年以來，Git 日臻成熟完善，在高度易用的同時(shí)，仍然保留著初期設(shè)定的目標(biāo)。 它的速度飛快，極其適合管理大項(xiàng)目，有著令人難以置信的非線性分支管理系統(tǒng)（參見 Git 分支）。

• 1991 年 Linux 開發(fā)了 linux 系統(tǒng)這個(gè)開源項(xiàng)目，采用郵件發(fā)送源文件附帶patch的方式進(jìn)行寫作開發(fā)，由 Linux 本人進(jìn)行手工合并；

• 2002 年 BitKeeper 與 Linux 社區(qū)達(dá)成協(xié)議，允許 Linux 社區(qū)免費(fèi)試用 BitKeeper，由于免費(fèi)試用，協(xié)議內(nèi)容更多地是保護(hù) BitKeeper 自身。

• 2005 年 BitKeeper 不滿 Linux 社區(qū)破壞協(xié)議內(nèi)容（說白了就是反編譯 BitKeeper，試圖做破解版或其他），終止合作；

• 同 2005 年，Linux 花費(fèi)了 2 周時(shí)間，開發(fā)了 Git 第一版，一個(gè)月內(nèi)使用 Git 來管理 Linux 代碼；

Git 基礎(chǔ)知識(shí)

工作區(qū)(Workspace)、暫存區(qū)(Index)、版本庫(Repository)

# 創(chuàng)建并進(jìn)入 testGitFlow 目錄
# 此時(shí) testGitFlow 就是我們的工作區(qū)(Workspace)，也就是工作目錄

$ mkdir testGitFlow && cd testGitFlow

# 初始化 git 倉庫
# 此時(shí)目錄中增加了 .git 目錄，.git 目錄就是 git 倉庫，不屬于工作區(qū)

$ git init

# 新增兩個(gè)文件
$ echo 111 > a.txt
$ echo 222 > b.txt

# 添加兩個(gè)文件到暫存區(qū)/索引(Index)
$ git add .

# 把索引中的兩個(gè)文件添加到版本庫(Repository)
$ git commit -m 'init'

以上涉及的幾個(gè)概念：
Workspace: 簡(jiǎn)單理解就是我們的項(xiàng)目目錄
Index: 簡(jiǎn)單理解就是存儲(chǔ)即將提交的內(nèi)容的區(qū)域
Repository: 版本倉庫

Commit、Tree、Blob 對(duì)象

# 通過 git log 查看版本
$ git log

>
commit 2b304a56998989dbcfd77f370f4b43fcad9e5872 (HEAD -> master)
Author: huihuipan <huihuipan163@163.com>
Date:   Mon Feb 27 17:56:53 2023 +0800

    init


# 通過 git cat-file 查看 commit 信息

# 查看 commit 類型
$ git cat-file -t 2b304a
> commit

# 查看 commit 內(nèi)容
$ git cat-file -p 10d717

>
tree 4caaa1a9ae0b274fba9e3675f9ef071616e5b209
author huihuipan <huihuipan163@163.com> 1677491813 +0800
committer huihuipan <huihuipan163@163.com> 1677491813 +0800

init

# 可以發(fā)現(xiàn)有 tree, author, committer 等信息
# 繼續(xù)查看 tree 內(nèi)容
$ git cat-file -t 4caaa1
> tree

$ git cat-file -p 4caaa1
>
100644 blob 58c9bdf9d017fcd178dc8c073cbfcbb7ff240d6c	a.txt
100644 blob c200906efd24ec5e783bee7f23b5d7c941b0c12c	b.txt

# 可以發(fā)現(xiàn)有 blob 信息
# 繼續(xù)查看 blob 內(nèi)容
$ git cat-file -t 58c9bd 
> blob

$ git cat-file -p 58c9bd 
> 111

# 可以看到里面存儲(chǔ)的是 a.txt 的內(nèi)容

以上涉及的幾個(gè)概念：
commit: commit 記錄提交的版本
tree: tree 記錄不同版本下的目錄結(jié)構(gòu)和文件名
blob: blob 記錄文件內(nèi)容

修改文件及提交 commit 的時(shí)發(fā)生了什么？

1. 首先，a.txt 內(nèi)容 從 111 修改為 333，此時(shí) git 倉庫沒有變化，只是工作區(qū)和索引的內(nèi)容對(duì)不上了；

2. 執(zhí)行 git add 命令

1. git 倉庫根據(jù)新的 a.txt 內(nèi)容（333）創(chuàng)建出一個(gè)新的 blob 結(jié)點(diǎn)，記錄 a.txt 內(nèi)容

2. 索引從舊 blob 的指向新的 blob

3. 執(zhí)行 git commit 命令

1. 根據(jù)索引的狀態(tài)，生成 tree 對(duì)象

2. 根據(jù)新生成的 tree 對(duì)象和 上一個(gè) commit 對(duì)象，生成新的 commit 對(duì)象

3. 把分支指針從舊的 commit 對(duì)象移動(dòng)到新的 commit 對(duì)象

HEAD、Branch、Tag

Branch: 是指向 Commit 的指針，每一次提交新的commit，當(dāng)前的 Branch 都會(huì)指向最新的 commit;

HEAD: 指向 Branch 的指針，當(dāng)checkout 到非 branch 時(shí)，會(huì)提示處于分離頭指針狀態(tài)，可以做一些試驗(yàn)性的動(dòng)作;

Tag: 指向 Commit 的指針，用作標(biāo)簽，通常用作記錄固定版本，也可以理解為是指定 commit 的別名;

以上我們可以得知，git 的版本管理粒度去到了文件級(jí)別，blob 之間的對(duì)比即可得到 diff，這里也引申出了一個(gè)開發(fā)上的一個(gè)思考，當(dāng)我們的程序設(shè)計(jì)的基礎(chǔ)是一個(gè)比較小粒度的時(shí)候，后續(xù)開發(fā)和擴(kuò)展就會(huì)更加靈活，事實(shí)上git 對(duì)commit 的操作也是非常靈活，靈活到稍不注意就有可能釀成事故。

Checkout、Merge、Rebase、Fetch、Pull

checkout 檢出: 把 HEAD 檢出到指定 branch 或 commit，或者檢出指定版本指定文件的內(nèi)容，由于在 git 里面checkout 承載了太多的功能，所有切換分支有專屬命令 switch。

merge 合并:

rebase 變基:

rebase 會(huì)修改版本歷史，即使 rebase 前與 rebase 后的內(nèi)容一致，但版本不再是同一個(gè)版本

fetch: 從另一個(gè)存儲(chǔ)庫下載對(duì)象和引用，如遠(yuǎn)程庫

pull: git pull = fetch + merge

基于 Git 的幾種工作流

Git Flow

簡(jiǎn)介

主要分支

有兩個(gè)分支會(huì)貫穿整個(gè)版本的生命周期，也就是長(zhǎng)期分支：

• master 分支：用于發(fā)布

• develop 分支：用于開發(fā) master 分支和 develop 分支的關(guān)系如上，虛線部分指著兩個(gè)分支并不是直接發(fā)生關(guān)聯(lián)，而是通過 release/hotfix 分支發(fā)生關(guān)聯(lián)

支撐分支

• feature branches: 用于需求開發(fā)

開發(fā)需求時(shí)從 develop 分支拉出 feature 分支，feature 分支開發(fā)完畢后(開發(fā)自測(cè)無問題)則合并回 develop 分支，合并后刪除分支，后續(xù)出現(xiàn) bug 則在 develop 分支修改。

• release branches: 用于發(fā)布

當(dāng) develop 分支處于一個(gè)相對(duì)穩(wěn)定的狀態(tài)時(shí)即可從 develop 分支拉出 release 分支準(zhǔn)備發(fā)布，release 分支不進(jìn)行功能開發(fā)，僅進(jìn)行 bug 修復(fù)，直至無問題時(shí)合并到 master 分支進(jìn)行發(fā)布，同時(shí)合并回 develop 分支后刪除 release 分支。

• hotfix branches: 用于修復(fù)生產(chǎn)問題

hotfix 分支用于修復(fù)生產(chǎn)環(huán)境上急需修復(fù)的 bug, 當(dāng)生產(chǎn)環(huán)境出現(xiàn) bug 時(shí)，從 master 分支拉出 hotfix 分支，修復(fù)后合并回 master 分支進(jìn)行發(fā)布，同時(shí)合并到 develop 分支后刪除。

補(bǔ)充

在 2020年 Vincent Driessen 補(bǔ)充了一條反思筆記，大概說 Git Flow這種模式在持續(xù)交付的軟件下顯得復(fù)雜，可以考慮使用 Github Flow 而不是將 Git Flow 硬塞到項(xiàng)目中。

繼 Git Flow 之后 Adam Ruka 針對(duì) Git Flow 的技術(shù)細(xì)節(jié)做了優(yōu)化，提出了 One Flow

Github Flow

相對(duì)于 Git Flow，Github Flow 只有一條主干分支，通過 github 平臺(tái)加持增加 PR 流程： 進(jìn)行某功能開發(fā)時(shí)，從 master 分支拉出 feature 分支，完成功能后提交 pr, 讓相關(guān)人員進(jìn)行 review, review 期間仍可以對(duì) feature 進(jìn)行提交，直至確認(rèn)無問題后通過 pr, 可以把 feature 分支合并到 master 分支進(jìn)行發(fā)布

GitLab Flow

GitLab Flow 使用 master 分支作為開發(fā)分支，基于 master 分支另起發(fā)布分支 production
GitLab Flow 增加以下分支定義:
環(huán)境分支：當(dāng)你需要在不同環(huán)境發(fā)布不同的版本時(shí)使用
發(fā)布分支：當(dāng)項(xiàng)目需要發(fā)布不同的版本時(shí)使用，聲明了一個(gè)發(fā)布分支后，這個(gè)分支只會(huì)合并嚴(yán)重的漏洞修復(fù)更新。

持續(xù)發(fā)布

gitlab-flow 推薦使用 master 分支進(jìn)行開發(fā)，基于 master 分支另建 production 分支進(jìn)行發(fā)布，另外提出了 環(huán)境分支的概念，根據(jù)不同環(huán)境，逐層合并，最后匯總到 production 發(fā)布分支后進(jìn)行發(fā)布

版本發(fā)布

如果你的項(xiàng)目需要發(fā)布不同的版本, gitlab-flow 版本發(fā)布模式可能更適合，在持續(xù)發(fā)布模式下，不同的版本會(huì)有不同的發(fā)布分支進(jìn)行發(fā)布。

Aone Flow

Aone-flow 是以 master 分支為基礎(chǔ)，除 master 分支外其他都是臨時(shí)分支?；?master 分支拉出環(huán)境分支，環(huán)境分支之間不進(jìn)行任何關(guān)聯(lián)，獨(dú)立發(fā)展，環(huán)境分支也不允許直接修改，而是通過合并不同的 feature 分支進(jìn)行組合。 feature 分支直至合并到 發(fā)布分支后才會(huì)刪除。有點(diǎn)是操作粒度更高更可控，缺點(diǎn)是環(huán)境分支的內(nèi)容即使是一樣的，但版本歷史卻有可能不一致。

怎樣選擇版本控制

上面介紹了好幾種 flow, 從 gitflow 開始，gitflow 讓自由度超高的 git 得到了指導(dǎo)性的使用方式；
而 github-flow 又針對(duì)了 gitflow 的復(fù)雜性提出了極簡(jiǎn)版的 flow；
gitlab-flow 又針對(duì) gitflow 和 github-flow 過于復(fù)雜或過于簡(jiǎn)單的方式，提出了自己折中的方案，同時(shí)還給出了兩種交付方式（持續(xù)交付、版本交付）的方案；
最后也介紹了 AoneFlow，一種操作粒度更自由的方案。

其實(shí)沒有一種萬能方案，不同的團(tuán)隊(duì)/項(xiàng)目有著其特殊的情況，針對(duì)不同情況，flow 也在變化，合適的就是最好的。

到此，相信大家對(duì)“Git的工作流有哪些”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！