四、標簽管理

4.1、標簽的理解

在使用 Git 進行版本管理時，**標簽（Tag）**扮演著非常重要的角色。它其實就是對某次提交（commit）的一個簡潔標識，相當于給這次提交起了一個可讀、易記的“別名”。比如，當項目發布一個正式版本時，通常會在最后一次提交上打上像 v1.0 這樣的標簽，以此來標識版本的里程碑。

標簽的出現解決了一個非常實際的問題：commit id 過長且難以記憶。雖然 commit id 唯一且精確，但當我們想要回到某個重要版本、修復 bug 或對比差異時，記憶一串哈希值顯然不太現實。而標簽為我們提供了一個更直觀、更友好的方式。

舉個例子：
當你需要將項目回退到上一次發布的 v1.0 版本時，只需執行類似：

git checkout v1.0

就能瞬間定位到對應的提交。這比手動復制粘貼 commit id 簡單得多。

因此，標簽不僅是對代碼的一次快照，更是項目迭代過程中的一個個“路標”。它讓我們能更清晰地管理和回溯不同的版本階段，尤其是在團隊協作或發布流程中，標簽的使用顯得尤為關鍵。

4.2、標簽的使用

創建標簽

想要進行創建標簽時，首先需要切換到要進行打標簽的分支上，然后進行執行下面的命令

git tag + 想要進行打標簽的名稱

默認進行打標簽是打在最新提交的 commit 上的，想要在指定的commit 上進行打標簽如何進行呢？

通過下面命令先進行產看指定的提交

git log --pretty=oneline --abbrev-commit

然后通過

git tag + 想要進行打的標簽名稱 指定的commit ID

Git還提供可以創建帶有說明的標簽，用-a指定標簽名，-m指定說明文字字，格式為:

git tag -a [name] -m "XXX" [commit_id]

查看標簽含義

git show + 標簽名??

刪除標簽

git tag -d + 標簽名

推送本地標簽到遠程倉庫

• 推送指定的標簽到遠程倉庫

git push origin + 標簽名稱

• 推送所有的標簽到遠程倉庫

git push origin --tags

進行刪除推動送到遠端的標簽

刪除推送到遠端的標簽一般分為兩步

1. 先進行刪除本地的標簽

直接執行上面介紹過的刪除標簽的命令。

2. 將本地的標簽進行推送到遠程倉庫

git push origin :+標簽名稱

五、多人協作

5.1、在同一分支下進行多人協作開發

1.在gitee上進行創建分支（dev分支）

2.查看遠程倉庫的分支?

git branch -r

如果沒有看到在遠程倉庫上新建的分支，進行執行pull命令進行拉取。?

3.在本地進行創建分支并且和遠端的分支進行建立聯系

git checkout -b dev origin/dev

為了進行模擬多人協作開發，即在Linux下進行創建了本地分支并且進行連接到遠程分支上，又在window 下進行創建本地分支模擬協同開發?

Linux下進行模擬一個開發人員

widow?下進行模擬一個開發人員

在同一分支下進行開發的步驟如上圖所演示的

目的：我們開發者人員首先需要在dev分支上進行開發后在進行合并到遠端的maser分支上。

首先每個開發者都需要先進行克隆遠端倉庫（前提條件），并且在遠端倉庫進行創建一個dev分支。

然后進行創建分支并且進行連接遠端倉庫

git checkout -b dev origin/dev

然后每個開發者都進行添加并提交對于代碼文件的修改，并推送到遠端倉庫中（這個過程是有很大概率是沖突的，需要進行解決沖突）

最后就是將dev分支進行合并到master總分支上

有兩種方如下：

• 第一種是在遠程倉庫中進行填寫合并表單的形式（推薦）

通過填寫合并分支的表單，然后通過審查人員（在企業中一般是leader）的審查后，沒有問題的話直接就將dev分支進行了向master進行合并。

• 第二種方式就是通過命令行的形式

首先需要在本地master 分支下進行pull拉取一下。

在參與的7開發者的本地進行合并master分支（這個過程是可能有沖突的），防止在mater上進行解決沖突出現BUG 問題。

最后在重新切換到master分支下進行合并dev分支。

總結一下，其實在同一分支下進行多人協作的流程是這樣：

• 首先，試圖用git push 進行推送自己的修改
• 如果推送失敗，則可能是遠程倉庫相對于本地倉庫更新，需要執行 git pull 試圖合并
• 如果合并有沖突，需要進行解決沖突
• 然后進行git push 推送到遠程倉庫
• 最后進行刪除分支

注意：其實多人在同一分支下進行協作開發的場景是很少的，可以說是幾乎不存在，因為多人在同一分支下進行開發，基本進行git pull 進行合并的時候都是由沖突的，而且進行解決沖突是一件非常麻煩的事情，我們通常都是是使用在不同分支下進行多人協作開發。

5.2、在不同分支下進行多人協作開發

• 一種方式進行實現（利用可視化的方式在遠程進行創建分支）

1.在遠程倉庫進行新建兩個分支 feature-1和feature-2

2.不同的開發者在本地進行創建分支并且和遠程分支進行建立聯系

3.分別進行向遠程分支進行添加推送

4.將遠程分支中的內容進行合并到主分支中（合并邏輯在下面進行演示）

• 另一種方式進行實現（全部進行使用命令行的形式）

1.不同的開發者在本地進項創建分支和文件進行提交

2.然后推送到遠端倉庫

git push origin 想要進行推送到遠端倉庫的名稱

在進行向遠端倉庫進行推送的時候，由于我們是還沒有進行創建遠端倉庫的，直接進行執行push命令是不能進行成功push的，在進行執行push的時候需要進行執行上述命令，代表創建遠程倉庫并進行將本地倉庫進行推送到該遠端倉庫。?

3.另一個開發者也是這樣的操作

在進行執行合并分支的邏輯之前，在不同的分支下進行多人協作開發是沒有經歷到沖突的。

假如說我們的小伙伴由于每天進行加班肝的太嚴重了，住進了醫院，但是他的開發還沒有完成，我們需要進行從本地倉庫中進行將他的分支進行拉取下來，替他進行開發維持項目的進度

1.想要對他的代碼進行開發，首先要進行找到小伙伴的代碼

git push

這里進行拉取既可以進行拉取本分支的內容（建立聯系），還可以進行拉取倉庫中的內容?

2.然后在本地進行創建分支并進行建立聯系

git checkout -b 分支名 origin/遠程倉庫分支名

3.將開發的代碼進行提交并推送到遠程倉庫中

執行git三板斧的操作

小伙伴康復回歸，重新進行開發?

??將本地分支和遠程分支進行建立聯系

git branch --set-upstream-to=origin/遠程分支 本地分支

然后進行拉取

git pull

4.進行合并分支

將上面步驟直接進行總結成：?

• 切換至?master分支, pull ?下，保證本地的master是最新內容。（合并前這么做是?個好習慣）
• 切換? feature-1 分支, 合并 master 分支?，這么做是因為如果有沖突，可以在feature-1分支上進行處理，?不是在在master上解決沖突。 （這么做是?個好習慣）??
• 由于feature-1分支已經merge進來了新內容，為了保證遠程分支最新，所以最好push?下。
• 要 push 的另?個原因是因為在實際的開發中，master的merge操作?般不是由我們自己在本地進 其他?員或某些平臺merge時，操作的肯定是遠程分支，所以就要保證遠程分支的最新。?如果 merge 出現沖突，不要忘記需要commit才可以push!!
• 切換至 master 分支，合并feature-1分支
• 將master分支進行推至遠端
• 最后將分支進行刪除

5.3、解決gitbranch-a 進行打印已經被刪除的遠程分支

先執行下面命令進行查看遠端分支?

git remote show origin

?進行在本地也進行刪除遠端被刪除的分支

git remove prune origin

?六、?企業級開發模型

6.1、企業級開發流程

一般流程

?在企業中我們要進行上線一個軟件，要經歷以下歷程 開發 →?測試 → 發布上線?，其中開發又包括 規劃、編碼、構建，發布包括：發布、部署和維護。

其中

• 開發團隊?:? 寫寫寫，根據業務需求進行實現
• 測試團隊：測測測，對開發人員的代碼進行測試
• 運維團隊：穩穩穩，維持服務器的穩定

通過上面的介紹，可以看到開發團隊和運維團隊是存在利益沖突的

DevOps：打破“開發”和“運維”的隔閡

在傳統的 IT 組織里，開發團隊 (Dev) 和 運維團隊 (Ops) 常常存在不同的訴求和目標。
開發這邊，尤其是敏捷團隊，更看重快速的交付和頻繁的變化；而運維那邊，最關心的是線上環境的穩定。
這兩邊如果各做各的，往往就會出現“部門墻”——開發想要快速上線新功能，運維卻得控制風險和變更。
結果呢？大家都不開心，IT 的整體價值也打了折扣。

為了解決這個矛盾，DevOps 這個概念就應運而生了。
DevOps 是 Development（開發） 和 Operations（運維） 的組合詞，它不僅僅是一個工具或者流程，而是一種文化、運動、一套最佳實踐。
核心目的很簡單：讓開發和運維能更好地溝通、合作，盡可能多地通過自動化來打通從開發到上線的流程，讓軟件的交付速度更快、發布更可靠。

從大流程來看，DevOps 貫穿了：
計劃 → 編碼 → 構建 → 測試 → 預發布 → 發布 → 運維 → 監控
這套流程真正做好的話，能顯著加快我們的軟件交付，減少線上事故的風險，提升用戶體驗。

---

?DevOps 跟咱們的 Git 有啥關系？

說了這么多，DevOps 到底和咱們平時學的 Git 有啥關系？
其實非常直接：
軟件的每一次迭代，本質上就是在改動代碼，代碼管理 就成了核心問題。
不管是做自動化測試、自動化部署，還是回滾 Bug 修復，代碼版本管理都離不開。
而 Git，作為當前最流行的分布式版本控制系統，簡直就是 DevOps 流程里的“血液”。
它讓我們能夠在多次迭代、多版本并行的情況下，依然有條不紊地管理代碼，也給后續的自動化流程（比如 CI/CD）打下了最堅實的基礎。

所以，Git 不光是咱們開發過程中“個人必備工具”，更是整個 DevOps 體系里不可或缺的基石。
有了它，咱們的迭代才能真正快又穩，才能讓 DevOps 真正發揮它的威力！

6.2、系統開發環境

在咱們日常做系統開發的時候，環境管理是繞不開的一塊。平時我們會遇到好幾種不同的環境，每個都有自己的用處，下面給大家聊一聊：

開發環境

就是我們日常擼代碼的環境。一般來說，開發環境的容錯和提示都開得很全，各種錯誤信息、調試工具都開著，目的就是讓開發更順暢，出錯能立馬定位。

測試環境

測試環境的作用可不小。咱們寫好的代碼不能直接上線吧？必須在測試環境先跑一跑，確保基本沒啥問題。測試環境就像是代碼上線前的“體檢中心”。

預發布環境

別小看了它！很多公司都會單獨搞個預發布（或者叫灰度/仿真）環境，盡量模擬生產環境的配置，提前找出線上可能出現的坑。它一般是和生產環境非常像，但又獨立出來的，專門用來讓咱們發版更安心。

生產環境

這個不用多說，就是用戶能直接用到的“正式版”環境，所有線上跑的服務都在這。對用戶來說，看到的都是生產環境的服務。

從大的流程上來說，咱們的項目一般會走：
開發 → 測試 → 上線。
如果公司規模再大點，可能還有更多：比如仿真環境、灰度環境、多個版本的測試環境……都為了讓上線更靠譜。

?重點來了
一個項目從想法到成功，測試是繞不開的。完善的測試體系能讓我們在上線前解決絕大部分致命 Bug，雖然測試不直接產生收益，但它才是產品質量的最后一道防線。也能反映一個團隊、一個公司的成熟度。別看它不“顯眼”，能不能搞好測試，往往決定了項目能不能成！

6.3、Git分支設計模型?

在前面聊到的多環境（開發、測試、預發布、生產）和 DevOps 流程中，代碼管理 是非常核心的一塊。而對于代碼管理，Git 是我們的得力助手。
但是，光有 Git 還不夠。要讓多人協作高效、避免踩坑，就得有一套合理的 分支模型。下面分享一個企業中常用的 Git 分支模型，通常也被稱為 Git Flow。

不同崗位對分支有不同的需求：

開發人員 自然是在“開發分支”上寫新代碼；

測試人員 則更想要一個單獨的分支，能隨時拿到他們需要測試的版本。
所以，為了讓大家各司其職又能高效協作，咱們就得好好設計一個合適的 Git 分支模型。

常用分支及適用環境

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

這套分支和環境的搭配只是常見的一種實踐，不是“放之四海而皆準”的真理。每個公司、每個團隊都可能有不同的調整。

---

各分支的職責

master 分支

• 只讀、唯一，直接關聯到線上生產環境。

• 一般只從 release 分支合并而來，所有代碼都非常穩定。

• 發布上線后，要打上 tag（標簽）來方便追溯。

• 禁止直接在 master 分支上開發。

release 分支

• 預發布分支，給測試人員用來做全面測試。

• 基于 develop 分支創建，合并了所有 feature 分支的內容。

• 命名方式：release/版本號_時間戳，比如 release/v1.2_20250610。

• 這個分支是臨時的，等發布完成后可選擇刪除。

develop 分支

• 統一的開發分支，永遠保持最新的可用代碼。

• 所有 feature 分支開發完成后都要合到這里，不能直接在上面開發（除非是特別小的修改）。

• 也是后續發布 release 分支的基礎。

feature 分支

• 針對具體新需求或功能點的開發分支。

• 命名方式：feature/功能_作者_時間，比如 feature/login_ys_20250610。

• 開發完合到 develop 分支，功能上線后可刪除。

hotfix 分支

• 用于線上版本的緊急修復（補丁）。

• 直接基于 master 分支創建。

• 命名方式：hotfix/問題_作者_時間，比如 hotfix/crashfix_ys_20250610。

• 修復完成后，要合到 master 和 develop 兩個分支，并推送遠程，修復上線后即可刪除。

---

Git Flow 模型：適用不等于萬能

其實上面介紹的就是很多企業常用的 Git Flow 分支管理模型。它能很好地滿足多環境、多人協作的需要，讓每個角色都能在各自的分支上做事，流程清晰可控。
不過，Git Flow 也并非“唯一解”。如果你所在的團隊是做 持續交付 的，或者更想簡化流程，也可以嘗試更輕量的模型，比如基于主干的開發模式（Trunk-Based Development）、使用特性標志（Feature Flags）等等。

關鍵是：
不要盲目追隨別人的分支模型
要根據自己團隊和項目的情況，去選適合自己的方式

因為，分支模型最終的目的，就是讓咱們的軟件開發和協作更高效、更安全。工具、流程再好，也得服務于人的需求，才算真正有價值。

Git flow模型并不是所有的公司都進行使用的很多公司使用自己獨立開發的模型，例如阿里的飛流flow分支模型，不同的團隊的需求不同進行選擇的分支模型就不同。

七、企業級項目管理實戰

創建模型的時候進行選擇master feature分支

企業名稱可隨意填寫?個測試名稱，只要能通過即可。注意，多?協作開發，需要將多?賬號拉?? 個企業下才?。如何添加成員后?會跟?家講解。

創建項目

?創建倉庫?

?

注： ?創建的倉庫可以關聯到某個項?中被管理 ?

添加成員

1. 添加企業成員

?申請后需要審批人員進行同意方可加入。

2.添加項目成員

3.添加倉庫成員

開發場景-基于git flow模型的實踐

新需求的加入

現有一個訂單管理的新需求進行加入，首先可以基于 develop 分支創建?個?feature/hyb_order_20231012 分?。

1. 需求在 feature/hyb_order_20231012 分?開發完畢，這時研發?員可以將代碼合并到?develop 分支，將其部署在開發環境的服務器中，方便開發?員進行測試和調試。

a. 開發者在 feature 分支下發起請求評審?

?b.審查員進行審核代碼

?

c.審查通過，進行合并分支

d.合并成功進行查看結果

2.在develop 下開發人員自測通過后，先確定下 develop 不存在未測試完畢的需求，然后研發人員可基于 develop 分支創建?個 release/xxx 分支出來，可交由測試?員進行測試。

3.測試?員測試 release 通過后（包含測試環境和預發布環境的測試），就可將代碼合并入?master。?

4. 測試?員在 master (正式環境) 測試通過后，便可刪除 feature/xxx 分支。

修復測試環境 Bug

當 develop 分支的測試環境出現 Bug，建議大家直接在 feature 分支 上進行修復。

修復后的提測、上線流程與新需求的加入流程一致，確保在開發階段就保持分支的健康和可控性。

---

修復預發布環境 Bug

當 release 分支的測試環境出現 Bug，修復步驟如下：

回歸檢查：先檢查 develop 分支 是否也存在該 Bug。
修復流程：

• 如果 develop 分支 也有該問題，修復流程與測試環境 Bug 修復一致；

• 如果 develop 分支 沒有該問題，這種情況一般比較少，往往是數據兼容問題或者環境配置問題，需要單獨定位和解決。

---

修復正式環境 Bug

當 master 分支的正式環境出現 Bug，修復步驟如下：

回歸檢查：先檢查 release 分支 和 develop 分支 是否同樣存在該問題。
修復流程：

• 如果存在，修復流程與測試環境 Bug 修復流程一致；

• 如果不存在，這種情況也比較少，大多是數據兼容問題或者環境配置問題，需要重點排查。

---

緊急修復正式環境 Bug

有時候，Bug 在測試環節未能發現，但在正式上線一段時間后才出現，屬于緊急修復 Bug。此時，流程如下：

建議先驗證下 預發布環境，即使有些企業在面對緊急修復時跳過了這一步。
基于 master 分支創建一個 hotfix/xxx 分支。
修復完成后，發布到 master 進行驗證。
驗證完畢后，將 master 代碼合并回 develop 分支，并刪除臨時的 hotfix/xxx 分支。