如何分析git的知識

這篇文章將為大家詳細講解有關如何分析git的知識，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

分支管理策略

git 分支強大的同時也非常靈活，如果沒有一個好的分支管理策略，團隊人員隨意合并推送，就會造成分支混亂，各種覆蓋，沖突，丟失等問題。

目前最流行的分支管理策略，也稱工作流（Workflow），主要包含三種：

• Git Flow

• GitHub Flow

• GitLab Flow

我司前端團隊結合實際情況，制定出自己的一套分支管理策略。

我們將分支分為 4 個大類：

• dev-*

• develop

• staging

• release

dev-* 是一組開發分支的統稱，包括個人分支，模塊分支，修復分支等，團隊開發人員在這組分支上進行開發。

開發前，先通過 merge 合并 develop 分支的最新代碼；開發完成后，必須通過 cherry-pick 合并回 develop 分支。

develop 是一個單獨分支，對應開發環境，保留最新的完整的開發代碼。它只接受 cherry-pick 的合并，不允許使用 merge。

staging 分支對應測試環境。當 develop 分支有更新并且準備發布測試時，staging 要通過 rebase 合并 develop 分支，然后將最新代碼發布到測試服務器，供測試人員測試。

測試發現問題后，再走 dev-* -> develop -> staging 的流程，直到測試通過。

release 則表示生產環境。release 分支的最新提交永遠與線上生產環境代碼保持同步，也就是說，release 分支是隨時可發布的。

當 staging 測試通過后，release 分支通過 rebase 合并 staging 分支，然后將最新代碼發布到生產服務器。

總結下合并規則：

• develop -> (merge) -> dev-*

• dev-* -> (cherry-pick) -> develop

• develop -> (rebase) -> staging

• staging -> (rebase) -> release

為什么合并到 develop 必須用 cherry-pick？

使用 merge 合并，如果有沖突，會產生分叉；dev-* 分支多而雜，直接 merge 到 develop 會產生錯綜復雜的分叉，難以理清提交進度。

而 cherry-pick 只將需要的 commit 合并到 develop 分支上，且不會產生分叉，使 git 提交圖譜（git graph）永遠保持一條直線。

再有，模塊開發分支完成后，需要將多個 commit 合為一個 commit，再合并到 develop 分支，避免了多余的 commit，這也是不用 merge 的原因之一。

為什么合并到 staging/release 必須用 rebase？

rebase 譯為變基，合并同樣不會產生分叉。當 develop 更新了許多功能，要合并到 staging 測試，不可能用 cherry-pick 一個一個把 commit 合并過去。因此要通過 rebase 一次性合并過去，并且保證了 staging 與 develop 完全同步。

release 也一樣，測試通過后，用 rebase 一次性將 staging 合并過去，同樣保證了 staging 與 release 完全同步。

commit 規范與提交驗證

commit 規范是指 git commit 時填寫的描述信息，要符合統一規范。

試想，如果團隊成員的 commit 是隨意填寫的，在協作開發和 review 代碼時，其他人根本不知道這個 commit 是完成了什么功能，或是修復了什么 Bug，很難把控進度。

為了直觀的看出 commit 的更新內容，開發者社區誕生了一種規范，將 commit 按照功能劃分，加一些固定前綴，比如 fix:，feat:，用來標記這個 commit 主要做了什么事情。

目前主流的前綴包括以下部分：

• build：表示構建，發布版本可用這個

• ci：更新 CI/CD 等自動化配置

• chore：雜項，其他更改

• docs：更新文檔

• feat：常用，表示新增功能

• fix：常用：表示修復 bug

• perf：性能優化

• refactor：重構

• revert：代碼回滾

• style：樣式更改

• test：單元測試更改

這些前綴每次提交都要寫，剛開始很多人還是記不住的。這里推薦一個非常好用的工具，可以自動生成前綴。地址在這里

首先全局安裝：

npm install -g commitizen cz-conventional-changelog

創建 ~/.czrc 文件，寫入如下內容：

{ "path": "cz-conventional-changelog" }

現在可以用 git cz 命令來代替 git commit 命令，效果如下：

然后上下箭選擇前綴，根據提示即可方便的創建符合規范的提交。

有了規范之后，光靠人的自覺遵守是不行的，還要在流程上對提交信息進行校驗。

這個時候，我們要用到一個新東西 —— git hook，也就是 git 鉤子。

git hook 的作用是在 git 動作發生前后觸發自定義腳本。這些動作包括提交，合并，推送等，我們可以利用這些鉤子在 git 流程的各個環節實現自己的業務邏輯。

git hook 分為客戶端 hook 和服務端 hook。

客戶端 hook 主要有四個：

• pre-commit：提交信息前運行，可檢查暫存區的代碼

• prepare-commit-msg：不常用

• commit-msg：非常重要，檢查提交信息就用這個鉤子

• post-commit：提交完成后運行

服務端 hook 包括：

• pre-receive：非常重要，推送前的各種檢查都在這

• post-receive：不常用

• update：不常用

大多數團隊是在客戶端做校驗，所以我們用 commit-msg 鉤子在客戶端對 commit 信息做校驗。

幸運的是，不需要我們手動去寫校驗邏輯，社區有成熟的方案：husky + commitlint

husky 是創建 git 客戶端鉤子的神器，commitlint 是校驗 commit 信息是否符合上述規范。兩者配合，可以阻止創建不符合 commit 規范的提交，從源頭保證提交的規范。

husky + commitlint 的具體使用方法請看這里

誤操作的撤回方案

開發中頻繁使用 git 拉取推送代碼，難免會有誤操作。這個時候不要慌，git 支持絕大多數場景的撤回方案，我們來總結一下。

撤回主要是兩個命令：reset 和 revert

git reset

reset 命令的原理是根據 commitId 來恢復版本。因為每次提交都會生成一個 commitId，所以說 reset 可以幫你恢復到歷史的任何一個版本。

這里的版本和提交是一個意思，一個 commitId 就是一個版本

reset 命令格式如下：

$ git reset [option] [commitId]

比如，要撤回到某一次提交，命令是這樣：

$ git reset --hard cc7b5be

上面的命令，commitId 是如何獲取的？很簡單，用 git log 命令查看提交記錄，可以看到 commitId 值，這個值很長，我們取前 7 位即可。

這里的 option 用的是 --hard，其實共有 3 個值，具體含義如下：

• --hard：撤銷 commit，撤銷 add，刪除工作區改動代碼

• --mixed：默認參數。撤銷 commit，撤銷 add，還原工作區改動代碼

• --soft：撤銷 commit，不撤銷 add，還原工作區改動代碼

這里要格外注意 --hard，使用這個參數恢復會刪除工作區代碼。也就是說，如果你的項目中有未提交的代碼，使用該參數會直接刪除掉，不可恢復，慎重啊！

除了使用 commitId 恢復，git reset 還提供了恢復到上一次提交的快捷方式：

$ git reset --soft HEAD^

HEAD^ 表示上一個提交，可多次使用。

其實平日開發中最多的誤操作是這樣：剛剛提交完，突然發現了問題，比如提交信息沒寫好，或者代碼更改有遺漏，這時需要撤回到上次提交，修改代碼，然后重新提交。

這個流程大致是這樣的：

# 1. 回退到上次提交
$ git reset HEAD^
# 2. 修改代碼...
...
# 3. 加入暫存
$ git add .
# 4. 重新提交
$ git commit -m 'fix: ***'

針對這個流程，git 還提供了一個更便捷的方法：
$ git commit --amend

這個命令會直接修改當前的提交信息。如果代碼有更改，先執行 git add，然后再執行這個命令，比上述的流程更快捷更方便。

reset 還有一個非常重要的特性，就是真正的后退一個版本。

什么意思呢？比如說當前提交，你已經推送到了遠程倉庫；現在你用 reset 撤回了一次提交，此時本地 git 倉庫要落后于遠程倉庫一個版本。此時你再 push，遠程倉庫會拒絕，要求你先 pull。

如果你需要遠程倉庫也后退版本，就需要 -f 參數，強制推送，這時本地代碼會覆蓋遠程代碼。

注意，-f 參數非常危險！如果你對 git 原理和命令行不是非常熟悉，切記不要用這個參數。

那撤回上一個版本的代碼，怎么同步到遠程更安全呢？

方案就是下面要說的第二個命令：git revert

git revert

revert 與 reset 的作用一樣，都是恢復版本，但是它們兩的實現方式不同。

簡單來說，reset 直接恢復到上一個提交，工作區代碼自然也是上一個提交的代碼；而 revert 是新增一個提交，但是這個提交是使用上一個提交的代碼。

因此，它們兩恢復后的代碼是一致的，區別是一個新增提交（revert），一個回退提交（reset）。

正因為 revert 永遠是在新增提交，因此本地倉庫版本永遠不可能落后于遠程倉庫，可以直接推送到遠程倉庫，故而解決了 reset 后推送需要加 -f 參數的問題，提高了安全性。

說完了原理，我們再看一下使用方法：

$ git revert -n [commitId]

掌握了原理使用就很簡單，只要一個 commitId 就可以了。

Tag 與生產環境

git 支持對于歷史的某個提交，打一個 tag 標簽，常用于標識重要的版本更新。

目前普遍的做法是，用 tag 來表示生產環境的版本。當最新的提交通過測試，準備發布之時，我們就可以創建一個 tag，表示要發布的生產環境版本。

比如我要發一個 v1.2.4 的版本：

$ git tag -a v1.2.4 -m "my version 1.2.4"

然后可以查看：

$ git show v1.2.4
> tag v1.2.4
Tagger: ruims <2218466341@qq.com>
Date:   Sun Sep 26 10:24:30 2021 +0800
my version 1.2.4

最后用 git push 將 tag 推到遠程：

$ git push origin v1.2.4

這里注意：tag 和在哪個分支創建是沒有關系的，tag 只是提交的別名。因此 commit 的能力 tag 均可使用，比如上面說的 git reset，git revert 命令。

當生產環境出問題，需要版本回退時，可以這樣：

$ git revert [pre-tag]
# 若上一個版本是 v1.2.3，則：
$ git revert v1.2.3

在頻繁更新，commit 數量龐大的倉庫里，用 tag 標識版本顯然更清爽，可讀性更佳。

再換一個角度思考 tag 的用處。

上面分支管理策略的部分說過，release 分支與生產環境代碼同步。在 CI/CD（下面會講到）持續部署的流程中，我們是監聽 release 分支的推送然后觸發自動構建。

那是不是也可以監聽 tag 推送再觸發自動構建，這樣版本更新的直觀性是不是更好？

諸多用處，還待大家思考。

永久杜絕 443 Timeout

我們團隊內部的代碼倉庫是 GitHub，眾所周知的原因，GitHub 拉取和推送的速度非常慢，甚至直接報錯：443 Timeout。

我們開始的方案是，全員開啟 VPN。雖然大多時候速度不錯，但是確實有偶爾的一個小時，甚至一天，代碼死活推不上去，嚴重影響開發進度。

后來突然想到，速度慢超時是因為被墻，比如 GitHub 首頁打不開。再究其根源，被墻的是訪問網站時的 http 或 https 協議，那么其他協議是不是就不會有墻的情況？

想到就做。我們發現 GitHub 除了默認的 https 協議，還支持 ssh 協議。于是準備嘗試一下使用 ssh 協議克隆代碼。

用 ssh 協議比較麻煩的一點，是要配置免密登錄，否則每次 pull/push 時都要輸入賬號密碼。

總之，生成公鑰后，打開 GitHub 首頁，點 Account -> Settings -> SSH and GPG keys -> Add SSH key，然后將公鑰粘貼進去即可。

現在，我們用 ssh 協議克隆代碼，例子如下：

$ git clone git@github.com:[organi-name]/[project-name]

發現瞬間克隆下來了！再測幾次 pull/push，速度飛起！

不管你用哪個代碼管理平臺，如果遇到 443 Timeout 問題，請試試 ssh 協議！

hook 實現部署？

利用 git hook 實現部署，應該是 hook 的高級應用了。

現在有很多工具，比如 GitHub，GitLab，都提供了持續集成功能，也就是監聽某一分支推送，然后觸發自動構建，并自動部署。

其實，不管這些工具有多少花樣，核心的功能（監聽和構建）還是由 git 提供。只不過在核心功能上做了與自家平臺更好的融合。

我們今天就拋開這些工具，追本溯源，使用純 git 實現一個 react 項目的自動部署。掌握了這套核心邏輯，其他任何平臺的持續部署也就沒那么神秘了。

終極應用: CI/CD

上面的一些地方也提到了持續集成，持續部署這些字眼，現在，千呼萬喚始出來，主角正式登場了！

可以這么說，上面寫到的所有規范規則，都是為了更好的設計和實現這個主角 ——— CI/CD。

首先了解一下，什么是 CI/CD ？

核心概念，CI（Continuous Integration）譯為持續集成，CD 包括兩部分，持續交付（Continuous Delivery）和持續部署（Continuous Deployment）

從全局看，CI/CD 是一種通過自動化流程來頻繁向客戶交付應用的方法。這個流程貫穿了應用的集成，測試，交付和部署的整個生命周期，統稱為 “CI/CD 管道”。

雖然都是像流水線一樣自動化的管道，但是 CI 和 CD 各有分工。

持續集成是頻繁地將代碼集成到主干分支。當新代碼提交，會自動執行構建、測試，測試通過則自動合并到主干分支，實現了產品快速迭代的同時保持高質量。

持續交付是頻繁地將軟件的新版本，交付給質量團隊或者用戶，以供評審。評審通過則可以發布生產環境。持續交付要求代碼（某個分支的最新提交）是隨時可發布的狀態。

持續部署是代碼通過評審后，自動部署到生產環境。持續部署要求代碼（某個分支的最新提交）是隨時可部署的。

持續部署與持續交付的唯一區別，就是部署到生產環境這一步，是否是自動化。

部署自動化，看似是小小的一步，但是在實踐過程中你會發現，這反而是 CI/CD 流水線中最難落實的一環。

為什么？首先，從持續集成到持續交付，這些個環節都是由開發團隊實施的。我們通過團隊內部協作，產出了新版本的待發布的應用。

然而將應用部署到服務器，這是運維團隊的工作。我們要實現部署，就要與運維團隊溝通，然而開發同學不了解服務器，運維同學不了解代碼，溝通起來困難重重。

再有，運維是手動部署，我們要實現自動部署，就要有服務器權限，與服務器交互。這也是個大問題，因為運維團隊一定會顧慮安全問題，因而推動起來節節受阻。

目前社區成熟的 CI/CD 方案有很多，比如老牌的 jenkins，react 使用的 circleci，還有我認為最好用的GitHub Action等，我們可以將這些方案接入到自己的系統當中。

關于如何分析git的知識就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。