企業開發工具git的使用：從入門到高效團隊協作

????????前言：本文介紹了Git的安裝、本地倉庫的創建與配置，以及工作區、暫存區和版本庫的區分。詳細講解了版本回退、撤銷修改等操作，并深入探討了分支管理，包括分支的創建、切換、合并、刪除及沖突解決。此外，還介紹了遠程操作，如遠程倉庫的創建與克隆，分布式版本控制的理解。最后，文章總結了系統開發環境和Git分支設計規范，強調了不同分支在開發、測試、預發布和生產環境中的作用。通過本文，您可以全面掌握Git的核心功能及其在團隊協作中的應用。

認識git

git安裝

創建本地倉庫

配置本地倉庫

工作區、暫存區、版本庫

版本回退

撤銷修改

刪除文件

分支管理

分支管理的理解

分支的創建、切換、合并

刪除分支

合并沖突

bug分支

強制刪除分支

遠程操作

理解分布式版本控制

遠程倉庫創建

克隆遠程倉庫

?編輯

git標簽管理?

多人協作1（單分支）

多人協作2（多分支）

系統開發環境

Git分支設計規范

本地操作

git安裝

安裝：

linux Centos：

sudo yum install git -y

linux Ubuntu：

sudo apt-get install git -y

?查看版本：

git --version

創建本地倉庫

git并不是對任意位置的文件都能維護，我們需要創建本地倉庫，如下：

創建目錄gitcode：

mkdir gitcode

初始化

git init

? ? ? ? git init：初始化一個新的 Git 倉庫。它的作用是將當前目錄轉換為一個 Git 倉庫（或創建一個空的 Git 倉庫），從而允許 Git 開始跟蹤該目錄下的文件變更。

初始化完成后，可以發現目錄下多了一個隱藏目錄.git

注意：不要手動修改.git目錄里的內容。

配置本地倉庫

創建完倉庫后注意name 和 email必須配置，要不然后續會出現各種問題。如下：

git config user.name 用戶名
git config user.name 電子郵件

查看配置結果：?

git config -l

刪除配置：

git config --unser user.name?
git config --unser user.email?

讓配置文件在所有倉庫中都生效（加--global選項即可），如下：

git config --global user.name 用戶名
git config --global user.email 電子郵件

刪除配置（加--global選項）

git config --global --unser user.name?
git config --global --unser user.email?

工作區、暫存區、版本庫

????????如上我們在新建目錄gitcode，并用git init指令初始化得到.git目錄。其中gitcode目錄下稱為工作區，而.git目錄下就是版本庫。

我們在對文件進行操作是在工作區的，但并未得到git的管理，還需要把它放到.git里。

注意：不能對.git目錄直接操作，會導致其內部結構錯亂。應使用相關指令進行操作。

?作區：是在電腦上你要寫代碼或?件的?錄。
暫存區：英?叫 stage 或 index。?般存放在?.git ?錄下的 index ?件（.git/index）中，我們把暫存區有時也叫作索引（index）。
版本庫：?名倉庫，英?名 repository 。?作區有?個隱藏?錄?.git ，它不算?作區，?是 Git 的版本庫。這個版本庫??的所有?件都可以被 Git 管理起來，每個?件的修改、刪除，Git都能跟蹤，以便任何時刻都可以追蹤歷史，或者在將來某個時刻可以“還原”。

.git里面還有一個對象庫，修改的工作區內容會寫入對象庫的一個新的git對象中。

使用指令：

git add 文件名

把工作區的文件存儲到暫存區，add后面可跟多個文件，后面跟 .（點）表示所有文件。

使用指令：

git commit -m "xxxx"

把暫存區數據推送到版本庫。其中xxxx表示你對此次修改的描述。

示例：

git log：查看提交記錄，按時間從近到遠。
git log --pretty=oneline：加選項--pretty=oneline，更簡潔美觀的顯示，如下：

其中黃色高亮的地方為<commit-id>是 Git 提交的哈希值，用來標識文件的唯一性。

使用指令：git cat-file -p <commit-id>，用于查看 Git 對象的原始內容，其中?-p?表示 "pretty-print"（格式化輸出）。

修改文件

Git追蹤管理的其實是修改，而不是整個文件。

修改文件readme，添加文本hello git

使用git status查看工作狀態，如下：

Git能追蹤到文件readme被修改，并顯示出“建議進行 git add和git commit”的字眼。

git diff 文件名：查看暫存區和工作區的文件差異，如下：

a：改動前
b：改動后
---：改動前
+++：改動后

指令：

git diff HEAD -- 文件名：查看版本庫和工作區的文件差異。

接下來進行add和commit，同時過程狀態的變化：

版本回退

指令：git reset [--soft | --mixed | hard ] [HEAD]

soft：只回退版本庫內容。
mixed（默認選項）：回退版本庫和暫存區內容。
hard（慎用）：回退所有區域的內容。
HEAD：當前版，也可以填寫指定的<commit-id>。

? ? ? ? 現有兩個版本的readme內容，老版本hello?git，新版本hello?git和hello word，下面簡寫為git和world：

以--hard選項為例測試：

那么如果我們回退后，后悔了想要回到剛才的狀態怎么辦？

再次通過git log查<commit-id>是查不到的，如下：

我們使用指令：git reflog即可查看，如下：

????????里面記錄你做過的各種操作，其中黃色高亮的為<commit-id>，“縮短版”的，但依舊能對得上。如下：

版本回退過程是非常快的，為什么回退那記錄？

????????git版本庫中主分支master指向當前版本的索引，即<commit id>，要進行版本回退，只需要改變master的指向即可。

撤銷修改

????????寫了一半寫不下去了，想重新開始寫該怎么辦？總不能一一刪除重新寫吧，我們更想要得到的是在最初開始寫的狀態。

? ? ? ? 而且我們寫的代碼可能已經推到暫存區，或版本庫了，要怎么把它撤銷？

解決方法：

場景一：?

手動刪（不推薦）
git指令：git checkout --?文件名

場景二：

指令git reset HEAD（回退到版本庫當前版本）再用git checkout -- 文件名。
直接用git reset --hard HEAD。

場景三：

指令：git reset --hard HEAD^

對于版本選項：

commit id：指定版本
HEAD：當前版本
HEAD^：上一個版本
HEAD^^：上上個版本
......

????????注意：一旦代碼推送到遠程倉庫就不能再撤銷了，撤銷的目的就是不影響遠程倉庫。遠程倉庫下文會講解。

????????撤銷修改：對提交過程的撤回。即工作區->暫存區->版本庫這個過程的撤回。主要是把撤銷回到工作區。

刪除文件

????????新增文件或刪除文件也是一種修改，要刪除暫存區或版本庫文件，只需要刪除工作區文件，然后進行add和commit即可。

可簡化為兩步：

git rm 文件名：工作區，暫存區文件都被刪除。
git commit -m “xxxx”：版本庫文件刪除。

分支管理

分支管理的理解

????????Git 的殺手锏之?：分?。分?就是科幻電影??的平?宇宙，當你正在電腦前努?學習 C++ 的時候，另?個你正在另?個平?宇宙?努?學習 JAVA。如果兩個平?宇宙互不?擾，那對現在的你也沒啥影響。不過，在某個時間點，兩個平?宇宙合并了，結果，你既學會了 C++ ?學會了 JAVA！

? ? ? ? 一個團隊要開發一個項目，每個讓可以延伸出一條分支，各自開發者負責自己的功能，最后進行測試再把它們進行合并在一起。

主分支master：是git最原始的分支，是整個git分支的跟。

分支的創建、切換、合并

git branch：查找分支。

????????其中我們會發現master前面有一個*，表示head指針指向master分支，也就是當前正在master分支下工作。

head指針：在開發過程中會有很多分支，head可以指向任意分支，head指向的分支為當前正在工作的分支。即*

使用cat查看HEAD內容，如下：

創建分支

git branch 分支名

示例：

查看.git結構，如下新增dev：

圖解：

注意：創建新分支（dev分支）的“根”是當前所在的分支。新分支的內容是基于最新提交的內容。

git checkout 分支名：切換分支

然后在dev分支下工作，最后合并到主分支。

合并分支：

git merge 分支名

注意：不能在dev分支下合并dev分支。只能在dev分支下合并master，或在master下合并dev。

刪除分支

合并后dev分支使命就結束了，最好把它刪除。

git branch -d 分支名：刪除分支，注意不能在dev分支上刪dev分支。

合并沖突

????????如果我們在基于a分支新增分支b，然后在b上修改，同時a分支也把數據修改，此時再把兩者合并時就會產生沖突。

????????如上圖，合并時會發生沖突，bbb和ccc只能保留一個，誰去誰留由程序員手動修改來決定。

測試：

指令：git checkout -b dev1

創建并同時切換到分支dev1。

????????打開沖突文件file，可以發現git給我們添加<<<<<HEAD，=========，>>>>>>>dev這樣的字眼，用來把兩個文件新增內容區分開：

????????現在需要合并，可以在master分支上刪除ccc，然后進行add，commit，再進行合并。或者在dev1分支上刪除bbb，然后進行add，commit，再合并。?

注意：添加的這些提示字眼也要刪除。

merge沖突需要手動解決，然后重新提交合并。

git log --graph? --abbrev-commit：圖示顯示提交過程

合并模式

如果我們創建分支dev2并且不產生沖突，進行合并，如下：

????????Fast-forward代表“快進模式”，Fast-forword模式（即ff）不能通過圖示區分是merge提交還是正常提交，如下：

建議在合并時，不使用fast-forword模式，即添加--no-ff選項，并且添加描述信息，-m選項。

git merge --no-ff -m “xxxxx” 分支名?

分支策略

保證主分支的穩定性

多人開發

bug分支

????????master出bug怎么辦？master不是100%沒bug。為保險起見不要直接在master主分支上直接修改。

首先使用指令：git stash

? ? ? ? 這是一個非常有用的 Git 命令，它允許你臨時保存工作目錄和暫存區的修改，而無需提交這些更改。當你需要快速切換分支但又不想提交未完成的工作時，stash 就特別有用。

怎么理解stash呢？

????????首先要明白，一個文件無論在任何分支下進行修改，只要沒有進行add和commit，就不屬于任何分支，而是屬于工作區，并未涉及版本庫。那么內容還不夠完善我們并不想進行add或commit，又想讓它屬于某個分支要怎么辦？使用git stash把數據保留在當前分支。

????????好的，言歸正傳，假設我們已經基于master分支創建新的分支dev3，并且在dev3分支中進行了開發，但突然發現原來分支中master有bug，該怎么解決？

保存數據：首先使用git stash指令保存當前分支的數據。
修復bug：切回到master分支，在此之上創建新的分支，假設為 fix_bug，在fix_bug分支上把bug修復，然后合并回master。
回到dev3上繼續開發（git stash pop：恢復最近的stash），開發完成進行add和commit。
因為在dev3開發期間master已經修改（bug修復），所以dev3與master合并時會出現沖突。
沖突解決：為了保證master主分支的穩定性，把master合并到dev3中，在dev3中解決沖突（即刪除bug代碼）。
沖突解決后dev3進行add和commit，再次進行合并。

關于stash的簡單使用：

git stash：把當前工作區數據保存到stash中。
git stash list：查看stash中有那些內容。
git stash pop：恢復最近的stash。

在解決沖突時可能會誤操作，弄出bug！所以在dev3上合并。

測試后再合并到master。?

強制刪除分支

????????比如在寫某個功能時創建了一個分支，但寫到一半時（此時沒有進行合并）發現，這個功能根本沒必要寫，把分支刪除吧。

此時使用指令git branch -d無法刪除，該指令只適用于合并后對分支刪除，沒合并會失敗。

git branch -D：強行刪除。

遠程操作

理解分布式版本控制

????????我們?前所說的所有內容（?作區，暫存區，版本庫等等），都是在本地！也就是在你的筆記本或者計算機上。?我們的 Git 其實是分布式版本控制系統！什么意思呢？
????????可以簡單理解為，我們每個?的電腦上都是?個完整的版本庫，這樣你?作的時候，就不需要聯?了，因為版本庫就在你??的電腦上。既然每個?電腦上都有?個完整的版本庫，那多個?如何協作呢？??說你在??電腦上改了?件A，你的同事也在他的電腦上改了?件A，這時，你們倆之間只需把各?的修改推送給對?，就可以互相看到對?的修改了。

但是這樣存在一個問題，要是自己電腦或對方電腦壞了怎么辦，數據不就找不回來了嘛。

????????在實際中使?分布式版本控制系統的時候，其實很少在兩?之間的電腦上推送版本庫的修改，因為可能你們倆不在?個局域?內，兩臺電腦互相訪問不了。也可能今天你的同事病了，他的電腦壓根沒有開機。因此，分布式版本控制系統通常也有?臺充當“中央服務器”的電腦，但這個服務器的作?僅僅是?來?便“交換”?家的修改，沒有它?家也?樣?活，只是交換修改不?便?已。有了這個“中央服務器”的電腦，這樣就不怕本地出現什么故障了（?如運?差，硬盤壞了，上?的所有東西全部丟失，包括git的所有內容）

中央服務器：24小時開機。

主要流行的有國外的GitHub和國內的gitee（碼云），下面我以gitee為例，講解如何使用。

遠程倉庫創建

首先注冊或登錄gitee
創建倉庫：

新建倉庫的界面：

????????創建倉庫并打開，我們可以發現它比本地倉庫多了三個文件，.gitfnore，README.en.md，README.md，如下：

.gitgnore文件：用來過濾不需要的文件，我們打開查看：

其中#表示注釋，*.swf表示過濾所有.swf后綴的文件。

????????我們可以手動對.gitgnore文件進行編輯，如果添加!a.swf表示a.swf文件不可被忽略。因為我們通常都不會把文件一個一個的推送到遠程，而是批量的推送，所以有些不重要的，無關的文件就會被推送上去，有了.gitgnore文件后起到了過濾的效果。

????????如果你的文件已經被?.gitignore?忽略，但仍然想強制添加到 Git 中，可以使用?git add -f（或?--force）命令。

git check-ignore -v 文件名：檢查一個文件是否已經被忽略

????????Readme：管理者（我們）來編輯Readme文件，填寫一些項目的介紹等，讓讀者快速了解項目的大體結構和功能，提供兩個模板：README.md為中文版，README.en.md為英文版。

????????issue模板：開發者（用戶）在使用你的服務或使用你的代碼過程中可能會發現一些bug，或者提出一些優化建議，Issue 模板?的主要作用是規范用戶提交 Issue 的格式和內容，幫助項目維護者更高效地收集、分類和處理問題或建議。

????????pull request模板：一個團隊成員（或貢獻者）在開發項目過程中，會基于你提供的主分支去創建一些子分支，進行功能開發，完成功能開發后會向你請求合并。Pull Request模板的作用是規范貢獻者提交代碼合并請求的格式和內容，幫助項目維護者高效審查代碼、減少溝通成本，并提升協作質量。

Issues為例：?

倉庫成員管理：

成員角色	權限
訪客（登錄用戶）	對于公有倉庫：創建 Issue、評論、Clone 和 Pull 倉庫、打包下載代碼、Fork 倉庫、 Fork 倉庫提交 Pull Request、下載附件
報告者	繼承訪客的權限。私有倉庫：不能查看代碼、不能下載代碼、不能 Push 、不能 Fork 、不能提交 Pull Request、可下載附件，不能上傳附件，不能刪除附件
觀察者	繼承報告者權限私有倉庫：創建 Wiki、可以 Clone 下載代碼、可以 Pull、不能 Fork
開發者	創建 Issue、評論、Clone 和 Pull 倉庫、Fork 倉庫、打包下載代碼、創建 Pull Request、創建分支、推送分支、刪除分支、創建 Issue 標簽（里程碑）、創建 Wiki、可上傳附件，可刪除自己上傳的附件，不能刪除他人上傳的附件、
管理員	創建 Issue、評論、Clone 和 Pull 倉庫、打包下載代碼、創建 Pull Request、創建分支、推送分支、刪除分支、創建 Issue/Pull Request 標簽（里程碑）、創建 Wiki、添加倉庫成員、強制推送分支、編輯倉庫屬性、可上傳附件，可刪除自己或他人上傳的附件、不能轉移/清空/刪除倉庫

倉庫成員權限說明 - Gitee.com

克隆遠程倉庫

????????克隆遠程倉庫（Clone a Remote Repository）?是指將網絡上的 Git 倉庫（如 Gitee、GitHub、GitLab 等平臺上的項目）完整復制到本地計算機的操作。

https模式

這里介紹兩種方式：?

ssh：需要公鑰加密，然后克隆。
https：直接克隆即可

https模式：

打開xshell，創建或選擇一個目錄，執行以下指令：

git clone 遠端倉庫鏈接

注意：不能在本地git倉庫里執行這個命令。

fetch和push 表示擁有拉權限和推權限。

????????origin是一個默認的遠程倉庫別名（Remote Alias），它指向你克隆（git clone）的原始遠程倉庫地址。它是 Git 用來標識遠程倉庫的快捷方式，方便后續操作（如推送、拉取代碼等）。當你執行?git clone?時，Git 會自動將遠程倉庫地址命名為?origin。

ssh模式

和https同樣的方法，進行克隆：

如下，我們是無法進行克隆的，因為沒有公鑰。?

需要把本地服務器公鑰放到git上進行管理。

打開gitee設置->打開ssh公鑰->設置公鑰。

????????獲取公鑰：打開本地主目錄（如linux的root目錄下）->在文件.ssh下看有沒有id_rsa（私鑰）和id_rsa.pub（公鑰），如果沒有先使用指令生成公鑰，如下：

ssh-keygen -t rsa -C "電子郵件"

執行命令后一直回車即可。

注意：電子郵件要和gitee的保持一致。看郵箱：打開gitee設置->郵箱管理。

????????然后復制id_rsa.pub文件的內容，粘貼到gitee公鑰配置的位置，點擊確定生成公鑰。完成以上操作后再進行克隆。

多人協作時可配置多個公鑰。

ssh模式的好處：

SSH 使用密鑰對認證（公鑰+私鑰），只要本地私鑰配置正確且添加到遠程倉庫（如 GitHub、GitLab），克隆或推送時無需重復輸入賬號密碼。
HTTPS 克隆可能需要每次輸入密碼（除非配置憑據緩存或使用 Personal Access Token）。
SSH 通過非對稱加密通信，防止中間人攻擊（如果服務器指紋受信任）。
HTTPS 雖然也加密，但若使用密碼認證且未配置二次驗證，可能存在風險（例如密鑰泄露）。

遠程推送操作

把本地版本庫的文件推送到遠端：

git push origin <本地分支>?: <遠端分支>

把遠端的數據拉取到本地：

git pull origin <遠端分支> : <本地分支>

注1：要成功推送，必須保證本地的數據要新于遠端的數據，如果不夠新，則先使用git pull拉取。其次就算沒有最新代碼也pull一下，是一個好習慣。

注2：配置 user.name和user.email和遠端一樣。

注3：pull不僅拉取，還順便進行了合并。

推拉操作

配置命令別名

git config --global alias.別名?原名

--global選項：全局生效。

所有git命令都能配置別名。

例如：

git標簽管理?

給最新提交版本打標簽：git tag 標簽名
給指定版本打標簽：git tag 標簽名 <commit-id>
看有那些標簽：git tag
查看指定標簽的詳細信息：git show 標簽名
給標簽加描述：git tag 標簽名?-m “xxxx” [<commit-id>]
刪除標簽：git tag -d 標簽名

推送標簽

推送指定標簽：git push origin 標簽名
推送所有標簽：git push origin --tags

刪除標簽有兩種方法：1.本地刪除然后推送到遠端。2.遠端刪除。

以方法1為例，假設要刪除標簽v1.0,：

1.本地刪除：

git tag -d v1.0

2.刪除結果推送到遠端

git push origin : v1.0

多人協作1（單分支）

目標：master分支下file.txt文件新增代碼"aaa", "bbb"

實現：開發者1新增"aaa"，開發者2新增"bbb"

條件在同一分鐘下協作完成。

一、遠端操作：新建一個分支，名為dev

二、本地操作：

開發者1：

克隆遠程倉庫。
創建本地分支dev。
vim創建并打開文件file.txt，添加"aaa"。
進行add，commit和push，推送到遠程。

第2部，在創建本地分支dev時可以順便與遠程的dev分支做連接。使用指令：git checkout -b dev origin/dev

checkout：創建分支
-b：切換到創建的分支
dev：分支名
origin/dev：與遠程分支dev建立連接??

????????建立連接有什么用呢？建立連接后推送時直接使用git push即可，拉取時直接使用git pull，而不需要使用指令git push origin <本地分支>?: <遠端分支>。

剛才是創建分支的同時建立連接，如果創建完分支后才想起來要建立連接怎么辦呢？

使用指令：git branch --set-upstream-to=origin/dev dev

git branch -a：查看所有分支情況，即本地分支和遠程分支。如下：

如果沒有顯示對應的遠程分支，使用git pull指令會把遠程分支同步到本地。

git branch -vv：查看本地分支與遠程分支的連接情況。如下：

開發者2：

克隆遠程倉庫。
創建本地分支dev。
vim創建并打開文件file.txt，添"bbb"。
進行add，commit和push，推送到遠程。

對于第二部的細節與以上所講相同。

????????對于第四部，如果開發者1先推送了file.txt，開發者2再推送就會發生沖突，即與遠端的file.txt發生沖突。如何處理沖突？

????????把遠端的文件pull拉取下來，然后修改file.txt，讓本地的file.txt同時有aaa和bbb。然后重頭開始執行第四部。

三、最后把遠程dev合并到master，兩種方法：

方法1：

申請并填寫合并申請單：

對于管理者，進行代碼測試和審核，然后合并：

方法二：在本地合并后推送到遠程的master分支（不推薦）。

最后dev分支用完就可以刪了。

多人協作2（多分支）

目標：遠端master分支下新增function1和function2。

實現：開發者1新增function1，開發者2新增function2。

條件：在不同分支下協作完成。

該協作方式更為靈活，有各自的分支實現對應的功能。

一、遠程操作：在遠程創建dev1和dev2分支分別給開發者1和開發者2使用。

二、本地操作：

開發者1：

如果沒有克隆倉庫先克隆。
創建自己的本地dev1分支并與遠程dev1分支連接。
創建并編輯文件function1。
進行add，commit和push

開發者2：

如果沒有克隆倉庫先克隆。
創建自己的本地dev2分支并與遠程dev2分支連接。
創建并編輯文件function2。
進行add，commit和push

????????注意：無論是開發者1還是開發者2在push之前都建議執行指令git pull，保證本地倉儲數據和遠程倉庫同步。

三、遠程操作：申請合并單把dev1和dev2合并到master主分支。

如果合并過程有沖突，我們在的次分支下解決沖突，再合并到master分支，如下：

系統開發環境

開發環境：開發環境是程序猿們專??于?常開發的服務器。為了開發調試?便，?般打開全部錯誤報告和測試?具，是最基礎的環境。
測試環境：?個程序在測試環境?作不正常，那么肯定不能把它發布到?產機上。該環境是開發環境到?產環境的過渡環境。
預發布環境：該環境是為避免因測試環境和線上環境的差異等帶來的缺陷漏測?設?的?套環境。其配置等基本和?產環境?致，?的是能讓我們發正式環境時更有把握！所以預發布環境是你的產品質量最后?道防線，因為下?步你的項?就要上線了。要注意預發布環境服務器不在線上集成服務器范圍之內，為單獨的?些機器。
?產環境：是指正式提供對外服務的線上環境，例如我們?前在移動端或PC端能訪問到的APP都是?產環境。開發人員不能直接把代碼部署到用戶能訪問到的服務器，而是有自己的服務器。即環境隔離。

Git分支設計規范

Git分支有很多模型，其中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 分?并推送遠程。?旦修復上線，便將其刪除。