【Git】企業級使用

?🔥個人主頁：?中草藥

?🔥專欄：【中間件】企業級中間件剖析

?基本概念

Git 有三個核心區域，分別是工作區、暫存區和版本庫，理解這三個區域是掌握 Git 的基礎。?

工作區就是我們電腦里能看到的文件目錄，比如我們在項目文件夾里寫代碼，這個文件夾就是工作區。舉個例子，我們在 “myproject” 文件夾里編寫 Java 代碼，這個 “myproject” 文件夾就是工作區，我們所有的代碼修改都在這里進行。?

暫存區就像一個臨時的中轉站，它位于.git 目錄下的 index 文件中。當我們在工作區完成文件修改后，需要先將這些修改提交到暫存區。比如我們在工作區修改了一個名為 “app.java” 的文件，通過 “git add app.java” 命令，就把這個修改后的文件添加到了暫存區，暫存區會記錄這些修改，等待我們進一步確認。?

版本庫也叫本地倉庫，它位于工作區目錄下的.git 隱藏文件夾中，里面包含了 Git 管理項目所需的所有信息，包括所有的版本數據、分支信息等。當我們把暫存區的內容提交到版本庫后，這些修改就被正式記錄下來了，形成一個新的版本。

基本使用

git的功能非常強大，其中，git中我們常見的操作有以下幾種

類別	命令	說明
倉庫初始化	`git init`	初始化當前目錄為 Git 倉庫
倉庫初始化	`git clone <url>`	克隆遠程倉庫到本地
文件操作	`git add <file>`	添加文件到暫存區
	`git rm <file>`	刪除工作區文件并暫存操作
	`git mv <old> <new>`	移動/重命名文件并暫存
提交更改	`git commit -m "消息"`	提交暫存區的更改并添加描述
提交更改	`git commit --amend`	修改最新一次提交（可追加更改或修改提交信息）
狀態查看	`git status`	查看工作區與暫存區狀態
	`git log`	顯示提交歷史
	`git diff`	比較工作區與暫存區的差異

下面對部分操作進行一個詳細介紹?

創建倉庫

以下操作均在Ubuntu界面呈現

初始化倉庫

????????要使用 Git 管理項目，首先需要初始化一個倉庫。在命令行中進入項目所在的目錄，例如我們的項目在 “D:\myproject” 文件夾下，輸入 “cd D:\myproject” 進入該目錄，然后輸入 “git init” 命令。?

????????執行這個命令后，會在當前目錄下生成一個隱藏的.git 文件夾，這個文件夾就是 Git 的版本庫，里面包含了 Git 進行版本控制所需的各種文件和配置信息（不允許在.git目錄下手動修改）。此時，我們就可以使用 Git 來管理這個項目了。

配置本地倉庫

使用git config 實現 git config --global 配置全局配置（一臺服務器可以實現多個本地倉庫）

添加文件

在工作區創建或修改文件后，需要將這些文件添加到暫存區。使用 “git add” 命令，其格式為 “git add < 文件名 >”。?

如果要添加當前目錄下的所有文件，可以使用 “git add .” 命令。例如，我們在工作區新建了 “index.html” 和 “style.css” 兩個文件，輸入 “git add index.html style.css” 可以將這兩個文件添加到暫存區；如果想添加所有修改的文件，輸入 “git add .” 即可。?

添加文件到暫存區的作用是告訴 Git，這些文件的修改是我們想要提交到版本庫的。

將暫存區的文件提交到版本庫，需要使用 “git commit” 命令，格式為 “git commit -m "提交說明"”。其中，“-m” 后面的字符串是對本次提交的描述，方便我們日后查看提交記錄時了解本次修改的內容。?

例如，我們將暫存區的文件提交到版本庫，輸入 “git commit -m "初次提交項目文件"”，執行后，版本庫就會記錄下這次提交的所有修改，形成一個新的版本。?

每次提交都會生成一個唯一的 commit ID，用于標識這個版本，我們可以通過這個 ID 回退到相應的版本。

可以通過git log查找日志

git reflog 用于查看本地的每一次提交命令

git status 查看工作區和緩存區的狀態

版本回退

git能夠維護版本的重要原因，便是它能夠靈活的回退版本

git reset [--soft | --mixed | --hard] [HEAD]

選項	工作區	暫存區	版本庫
（原本狀態）	A? B	A? B	A? B
--soft	A? B	A? B	A
--mixed（默認）	A? B	A	A
--hard（慎用）	A	A	A

撤銷修改

工作區	暫存區	版本庫	解決方式
A? B	A??	A??	1、手動撤銷（不推薦，容易出錯） 2、git checkout -- [filename]（推薦使用，--不能省略）
A? B	A? B	A	git reset --mixed
A? B	A? B	A? B	git reset --hard HEAD^（前提條件：commit之后沒有push）

命令別名

舉例：如給?git status 命令起一個別名可以用命令

git config --global alias.st status

分支管理?

基礎

分支是 Git 的核心功能，允許多線并行開發。

分支 = 指向提交的指針
每個分支都是一個指向某個提交（commit）的輕量級指針，默認分支通常為?main?或?master。

HEAD 指針：指向當前所在分支的指針（即工作目錄的狀態來源）。

常見操作?

命令	作用	示例
`git branch`	查看本地分支（`-a`?包含遠程分支，`-v`?顯示最近提交）	`git branch -av`
`git branch <name>`	創建新分支（不切換）	`git branch feature/payment`
`git checkout <branch>`	切換到已有分支	`git checkout dev`
`git checkout -b <new-branch>`	創建并切換到新分支（常用！）	`git checkout -b fix/issue-123`
`git merge <branch>`	合并指定分支到當前分支	`git checkout main` `git merge dev`
`git branch -d <branch>`	刪除已合并的分支	`git branch -d feature/old`
`git branch -D <branch>`	強制刪除未合并的分支（謹慎！）	`git branch -D experiment`
`git push origin <branch>`	推送分支到遠程倉庫	`git push origin feature/login`
`git push origin --delete <branch>`	刪除遠程分支	`git push origin --delete temp-branch`

與遠程分支建立連接

git checkout -b [dev] [origin/dev]git branch --set-upstream-to=origin/dev dev

合并沖突

當兩個分支修改了同一文件的同一區域時，合并會觸發沖突：?

此時需要手動解決并進行一次提交操作

沖突標記

<<<<<<< HEAD         # 當前分支的修改
當前分支的內容
=======
要合并分支的內容
>>>>>>> feature

可以通過

git log --graph --abbrev-commit 以試圖的方式查看分支

分支管理策略

1、快進合并（Fast-Forward）

條件：目標分支是當前分支的直接祖先（無分叉）。
效果：移動分支指針，不生成新提交（歷史線性）。

??在這種 Fast forward 模式下，刪除分支后，查看分支歷史時，會丟掉分支信息，看不出來最新提交到底是 merge 進來的還是正常提交的。

git支持我們強制禁用fast forward模式，在merge的時候會產生一個新的commit,這樣可以便于我們更好地去追溯這個改動是merge進來的還是commit的

git merge -no-ff -m ' ' dev

Bug分支

假如我們現在正在 dev2 分支上進行開發，開發到一半，突然發現 master 分支上面有 bug，需要解決。在Git中，每個bug都可以通過一個新的臨時分支來修復，修復后，合并分支，然后將臨時分支刪除。

舉例說明場景

此時，為了保存dev2中開發到一半的代碼

Git 提供了 git stash 命令，可以將當前的工作區信息進行儲藏，被儲藏的內容可以在將來某個時間恢復出來。

儲藏 dev2 工作區之后，由于我們要基于master分支修復 bug，所以需要切回 master 分支，再新建臨時分支來修復 bug

修復完成后，切換到 master分支，并完成合并，最后刪除fix_bug 分支:（假設情況如下圖）

先使用git stash pop去恢復現場此時狀態圖為

Master 分支目前最新的提交，是要領先于新建 dev2 時基于的 master 分支的提交的，所以我們在 dev2 中當然看不見修復 bug 的相關代碼。

我們的最終目的是要讓 master 合并 dev2 分支的，那么正常情況下我們切回 master 分支直接合并即可，但這樣其實是有一定風險的。

是因為在合并分支時可能會有沖突，而代碼沖突需要我們手動解決(在 master 上解決)。我們無法保證對于沖突問題可以正確地一次性解決掉，因為在實際的項目中，代碼沖突不只一兩行那么簡單，有可能幾十上百行，甚至更多，解決的過程中難免手誤出錯，導致錯誤的代碼被合并到 master上。此時的狀態為:

此時的解決辦法是在當前分支合并master，解決沖突之后，再去使用master合并dev

這只是某一種bug情況的提醒，實際的業務場景可能比這復雜的多

遠程操作

Git 的遠程操作是連接本地倉庫與遠程倉庫（如 GitHub、GitLab 等）的橋梁，用于實現多人協作和代碼同步。雖然 Git 是分布式系統，本地可以獨立工作，但實際開發中幾乎都需要通過遠程操作與他人共享代碼。

創建遠程倉庫-去往gitee去操作

clone 倉庫

git clone https://gitee.com/……

克隆后，本地會自動關聯遠程倉庫，別名為?origin

SSH 協議和 HTTPS 協議是 Git 最常使用的兩種數據傳輸協議。SSH 協議使用了公鑰加密和公鑰登陸機制，體現了其實用性和安全性，使用此協議需要將我們的公鑰放上服務器，由Git服務器進行管理。使用 HTTPS 方式時，沒有要求，可以直接克隆下來。

SSH

使用 SSH方式克隆倉庫，由于我們沒有添加公鑰到遠端庫中，服務器拒絕了我們的clone 鏈接。需要我們設置一下:

第一步:創建SSHKey。在用戶主目錄下，看看有沒有.ssh目錄，如果有，再看看這個目錄下有沒有id_rsa 和 id_rsa.pub 這兩個文件，如果已經有了，可直接跳到下一步。如果沒有，需要創建SSH Key:

ssh-keygen -t rsa -C "123456@qq.com"?

此時，順利的話，可以在用戶主目錄里找到.ssh 目錄，里面有id_rsa和 id_rsa.pub 兩個文件，這兩個就是SSH Key的秘鑰對，id_rsa 是私鑰，不能泄露出去，id_rsa.pub 是公鑰，可以放心地告
訴任何人

從遠程倉庫拉取代碼

pull操作實際上是pull + merge

拉取遠程倉庫的最新代碼到本地，并合并到當前分支：

# 拉取 origin 遠程的默認分支（通常是 main/master）并合并到本地當前分支
git pull origin# 拉取指定遠程分支（如 dev）并合并到本地當前分支
git pull origin dev# 首次拉取時可能需要指定本地分支與遠程分支的關聯
git pull origin dev:dev  # 拉取遠程 dev 到本地 dev 分支

注意：git pull?=?git fetch（獲取遠程更新） +?git merge（合并到本地）

向遠程倉庫推送代碼

push操作是分支與分支的操作

將本地倉庫的提交推送到遠程倉庫：

# 推送本地當前分支到 origin 遠程的對應分支（首次推送需要 -u 關聯）
git push -u origin main  # -u 表示設置默認關聯，后續可直接用 git push# 推送指定本地分支到遠程指定分支
git push origin dev:dev  # 本地 dev → 遠程 dev

忽略特殊文件

.gitignore

并不是所有文件都需要推送到遠程倉庫，比如本地的數據庫的配置信息，包含在.gitignore 的文件不會進行推送（可以使用git add -f 強制進行add）

上述的.gitignore文件配置了以下規則

忽略所有.so（Linux 共享庫）和.ini（配置文件）類型的文件

特殊排除 c.so 文件，使其能被 Git 追蹤

查看指定文件被哪些?.gitignore?規則匹配而被忽略，幫助排查「為什么某個文件沒被 Git 追蹤」的問題。

git check-ignore -v 文件名

-v（或?--verbose）：顯示詳細信息，包括?匹配的規則來源（哪個?.gitignore?文件）和?具體規則內容。

解決 git branch -a打印已被刪除的遠程分支的方法

git remote prune origin

標簽管理

基礎

在 Git 中，標簽（tag）是指向某個提交對象的固定指針，常用于標記特定版本，比如發布版本、里程碑版本等，方便快速定位到對應的代碼狀態。Git 的標簽分為輕量級標簽（lightweight tag）和附注標簽（annotated tag），以下是關于標簽管理的詳細介紹：

輕量級標簽實際上就是一個保存著對應提交對象的校驗和（哈希值）的文件，創建輕量級標簽非常簡單，命令格式如下：

git tag <tagname> [<commit>]

其中，<tagname>?是你要創建的標簽名，<commit>?是可選參數，用于指定標簽要指向的提交對象，若不指定，默認指向當前所在的提交對象。例如，在當前提交上創建一個名為?v1.0?的輕量級標簽：

git tag v1.0

附注標簽是存儲在 Git 數據庫中的一個完整對象，包含標簽名、打標簽者的名字和電子郵件地址、日期時間、標簽說明等信息。創建附注標簽使用?-a?選項，命令格式如下：

git tag -a <tagname> -m "<tag message>" [<commit>]

其中，-m?選項用于指定標簽的說明信息，<tag message>?就是標簽說明內容。比如，創建一個名為?v2.0?的附注標簽，并添加說明信息：

git tag -a v2.0 -m "這是項目的第二個正式發布版本"

查看標簽

列出所有標簽

使用以下命令可以列出當前倉庫中的所有標簽：

git tag

默認情況下，標簽會按字母順序列出。如果想按照創建時間順序列出標簽，可以使用?sort -V?命令進行排序：

git tag | sort -V

查看標簽詳細信息

要查看某個特定標簽的詳細信息，對于附注標簽，可以使用?git show?命令：

git show <tagname>

例如，查看?v2.0?標簽的詳細信息：

git show v2.0

對于輕量級標簽，git show?命令會顯示標簽指向的提交對象的詳細信息。

推送標簽

默認情況下，git push?不會推送標簽到遠程倉庫。要推送某個標簽到遠程倉庫，可以使用以下命令：

git push origin <tagname>

如果要一次性推送所有本地標簽到遠程倉庫，可以使用：

git push origin --tags

拉取遠程標簽

當遠程倉庫新增了標簽，你可以使用以下命令拉取遠程標簽到本地：

git fetch origin tag <tagname>  # 拉取單個標簽
git fetch origin --tags  # 拉取所有標簽

刪除標簽

可以直接在倉庫管理界面刪除

刪除本地標簽

要刪除本地的某個標簽，可以使用?-d?選項，命令格式如下：

git tag -d <tagname>

例如，刪除名為?v1.0?的本地標簽：

git tag -d v1.0

刪除遠程標簽

刪除遠程標簽需要先刪除本地標簽，然后通過?git push?命令將刪除操作同步到遠程倉庫，命令格式如下：

git push origin :<tagname>

例如，刪除遠程倉庫中的?v2.0?標簽：

git push origin :refs/tags/v2.0

使用標簽

在實際開發中，當需要切換到某個標簽對應的版本時，可以使用?git checkout?命令。不過，由于標簽是只讀的，直接?checkout?標簽會讓你處于 “分離 HEAD” 狀態（即 HEAD 指針直接指向某個提交對象，而不是指向某個分支）。如果要基于標簽創建一個新分支進行開發，可以使用：

git checkout -b <branchname> <tagname>

例如，基于?v2.0?標簽創建一個名為?feature/v2.0-dev?的新分支：

git checkout -b feature/v2.0-dev v2.0

標簽管理是 Git 中一個非常有用的功能，能夠幫助開發者更方便地管理項目版本，追蹤重要的代碼狀態。

Git Flow模型

一般根據不同的環境來設計分支

Git Flow 是一種常用的 Git 分支管理模型，由 Vincent Driessen 提出，適用于大型項目或多人協作的項目，它定義了一系列分支及其使用規則，以規范代碼管理和版本發布流程，以下是 Git Flow 模型中主要分支及其作用：

分支	名稱	適用環境
master	主分支	生產環境
release	預發布分支	預發布 / 測試環境
develop	開發分支	開發環境
feature	需求開發分支	本地
hotfix	緊急修復分支	本地

master 分支

master 為主分支，該分支為只讀且唯一分支。用于部署到正式發布環境，一般由合并 release 分支得到。
主分支作為穩定的唯一代碼庫，任何情況下不允許直接在 master 分支上修改代碼。
產品的功能全部實現后，最終在 master 分支對外發布，另外所有在 master 分支的推送應該打標簽（tag）做記錄，方便追溯。
master 分支不可刪除。

release 分支

release 為預發布分支，基于本次上線所有的 feature 分支合并到 develop 分支之后，基于 develop 分支創建。可以部署到測試或預發布集群。
命名以 release/ 開頭，建議的命名規則: release/version_publishtime 。
release 分支主要用于提交給測試人員進行功能測試。發布提測階段，會以 release 分支代碼為基準進行提測。
如果在 release 分支測試出問題，需要回歸驗證 develop 分支看否存在此問題。
release 分支屬于臨時分支，產品上線后可選刪除。

develop 分支

develop 為開發分支，基于 master 分支創建的只讀且唯一分支，始終保持最新完成以及 bug 修復后的代碼。可部署到開發環境對應集群。
可根據需求大小程度確定是由 feature 分支合并，還是直接在上面開發（非常不建議）。

feature 分支

feature 分支通常為新功能或新特性開發分支，以 develop 分支為基礎創建 feature 分支
命名以 feature/ 開頭，建議的命名規則: feature/user_createtime_feature 。
新特性或新功能開發完成后，開發人員需合到 develop 分支。
一旦該需求發布上線，便將其刪除。

hotfix 分支

hotfix 分支為線上 bug 修復分支或叫補丁分支，主要用于對線上的版本進行 bug 修復。當線上出現緊急問題需要馬上修復時，需要基于 master 分支創建 hotfix 分支。
命名以 hotfix/ 開頭，建議的命名規則: hotfix/user_createtime_hotfix
當問題修復完成后，需要合并到 master 分支和 develop 分支并推送遠程。一旦修復上線，便將其刪除。