Git在多人開發中的常見用例

前言

作為從一個 svn 轉過來的 git 前端開發，在經歷過git的各種便捷好處后，想起當時懵懂使用git的膽顫心驚：總是害怕用錯指令，又或者遇到報錯就慌的場景，想起當時查資料一看git指令這么多，看的頭暈眼花，根本不知道從何下手。

為了給一些小白以及初學者少走點彎路，我會根據在實際開發中，可能出現的場景，用實例結合部分理論。寫一篇關于git在多人開發中的操作解決指南，全文通俗易懂，很適合上手。

安裝Git

Git - Downloads

第一步肯定是先安裝呀，直接下載到電腦，一直下一步即可，如果遇到下載失敗等問題，這里直接百度即可，不做過多描述。

新建項目

至于為什么要講這一步，為了照顧到有些連這一步都不懂的小白（會的可以跳過）。假設你現在有了一個新項目，就需要在Gitee或者Github上新建一個倉庫，以下拿Gitee舉例（當然是Gitee是中文啦！），包括本人目前內部團隊也是用的Gitee企業版。

這里只做個人新建教學，如果你是公司內部負責人，你也可以免費新建企業版本（可以最多支持5個成員，如果有需求可以自行購買，企業新建項目流程跟個人差不多）

關于下面那三個選項：初始化倉庫、設置模板、選擇分支模型，這里就不做設置。

創建成功后就可以看到以下內容

部分小白看到這里可能就懵了：“怎么突然多了這么多指令，我到底要做哪個？”

好，那我們一步步去理解

HTTPS跟SSH的區別

這里為了方便演示，我們直接初始化 readme 文件（后續再刪）

在初始化之后，會自動生成兩個md文件，這里先不用管。我們直接點擊克隆/下載

有些初學者想把別人的項目代碼克隆到本地的時候，因為沒有學過git操作，通常可能選擇最直觀的方式：下載ZIP！，確實是最方便的操作，但是我們這里是為了多人開發去不斷修改代碼并提交到倉庫，所以我們要選擇HTTPS/SSH去拉取代碼。

這里的區別只講操作的區別，可以看到Gitee也提示我們在使用HTTPS的時候：

使用 HTTPS 協議時，命令行會出現如下賬號密碼驗證步驟。總結就是，如果不設置私人令牌，那你修改代碼后，推送代碼到倉庫/分支，每次都要都要輸入一次你的gitee賬戶密碼，特別麻煩！

切換到SSH

可以看到提示：初次使用SSH需要配置。看到這里有些初學者也有點懵：“這些指令又是什么意思?”

這里解釋一下什么是SSH協議作用（大概了解就行）：通過SSH操作遠程倉庫時，gitee/github需要對你的電腦的公鑰做一個校驗認證，只要你在你電腦設置過公鑰，以后每次操作都不需要做任何的認證校驗了。

總結就是：

HTTPS:操作簡單，復制https url然后到git Bash里面直接用clone命令克隆到本地。
缺點：每次fetch和push代碼都需要輸入賬號和密碼。很麻煩！

SSH：需要在克隆之前配置和添加好SSH。
優點：SSH默認是每次fetch和push代碼都不需要輸入賬號和密碼。

所以這里強烈推薦在你電腦上配置你的賬戶SSH！

配置SSH

我們可以在上面的彈窗中點擊打開你的SSH公鑰

可以看到我這里已經有了SSH公鑰了，分別對應我設置過的電腦，如果你的電腦還未配置過，可以查看SSH 公鑰設置

看到這里，有些小白還是不知道怎么配置，一看又是一大堆看不懂的指令，但其實就是跟著文檔全部敲一遍就可以了。

在跟著敲完后，復制你電腦輸出的SSH公鑰（注意是你電腦的，不是文檔的）

在復制完后就可以跟著繼續操作添加

再在你電腦上的Windows PowerShell 或者 Git Bash輸入：

ssh -T git@gitee.com

如果看到以下結果，就證明你的SSH配置成功了！

溫馨提示，SSH是根據機器識別的，也就是說，如果你在公司電腦配置了，但是你在家里電腦還未配置，就要再跟著上面的操作配置一遍即可。

配置Git用戶名和郵箱

我們可以看到在gitee克隆下載/彈窗中，不斷提示我們：為確保你提交的代碼身份被 Gitee 正確識別，請執行以下命令完成配置。

首先是為什么要配置用戶名跟郵箱？其實這兩個主要是用于本地修改代碼后commit信息會顯示修改人以及郵箱地址，也就是說這樣誰寫了這段BUG,在日后查找的時候一目了然！

創建用戶名和郵箱（同樣用于修改）

git config --global user.name "username"
git config --global user.email "xxx@xxx"

在你輸完以上兩行代碼后，可能發現沒反應？那就是好事，沒反應就是成功了！

所以你可以輸入以下兩行指令查看你剛才設置的用戶名跟郵箱

查看git用戶名和郵箱

git config user.name
git config user.email

在這里插入圖片描述

如果你最后的指令跟上圖差不多，那說明你的用戶名跟郵箱已經設置成功！

但是雖然說用戶名跟郵箱可以隨意設置（極其不建議這樣做！），最好是user.email跟你的Github郵箱或者gitee郵箱一致。

如果本地設定的user.email值與GitHub上的賬戶的郵件地址相同，GitHub會認定推送代碼的操作是賬戶擁有者自己做的，跟直接登錄到GitHub，從網站上修改，是相同的。此時，修改人是一樣，就是賬戶擁有者。
如果本地設定的user.email值與GitHub不同，也能把代碼推送到GitHub（只要密碼或者ssh正確），GitHub會記錄這次的修改是另一個人做的。

克隆代碼

這個較為簡單，就是把遠程代碼克隆到本地（這里使用SSH）

git clone git@你的項目地址.git

這樣就可以把你遠程的代碼克隆到本地啦

分支管理

在講到分支時，很多初學者可能不理解分支的作用，那我就根據在實際項目中的使用場景進行不同的解釋，其實分支基本算是Git的最大的作用了。

分支作用

在我們創建項目的時候，會有一個默認分支：master（生產環境），但在實際項目中，一般都需要一個dev分支（開發環境主分支）。而分支的作用通俗一點就是，相當于把你的項目拷貝各個子目錄，這些子目錄相互獨立。

那我們直接上場景！

場景1：公司已經有了項目，但是想使用git去管理

實際操作1：
剛才不是在Gitee新建了倉庫？但是倉庫什么都沒有（已把剛才那兩個md文件刪了，右鍵手動刪除即可）。

進入到你本地代碼目錄中空白處右鍵打開Git Bash，在該目錄中，我就用3個文件來模擬即可。

或者出去目錄外右鍵目錄打開Git Bash

分別輸入以下代碼：
初始化git(相當給你的目錄文件夾初始化一個git代碼庫)

git init

因為你已經在本地有代碼文件了，所以直接 git add . 添加當前目錄的所有文件到暫存區

git add .

這時候就要提交代碼了，利用指令： git commit -m '第一次初始化代碼' 把代碼提交暫存區到本地倉庫區，注意這個后面提交備注可以隨意填寫

git commit -m '第一次初始化代碼'

做完以上命令后，你的本地git倉庫已經保存完成了，這時候就得跟你剛才新建的Gitee遠程倉庫關聯起來

git remote add origin git@gitee.com:your_username/your-code-name.git

注意后面的url就是你在用SSH克隆的url

上面的指令意思其實也很簡單

git remote add：用于添加一個新的遠程倉庫。

origin:這是你給遠程倉庫設置的別名（通常是origin，但也可以是其他任何你喜歡的名字）

而最后面的URL就是你遠程倉庫URL。做完以上這些后，就可以把代碼從你的本地倉庫推送到遠程倉庫啦！

git push -u origin master

git push：用于將本地的更改推送到遠程倉庫。
-u：這個選項用于在推送的同時，將本地分支與遠程分支建立上游關系。這意味著之后你可以使用更簡短的命令（如git pull而不是git pull origin master）來拉取遠程分支的更改，因為Git會記住這個上游關系。
origin：這是遠程倉庫的別名。
master：這是你要推送的本地分支的名稱，以及你希望它在遠程倉庫中對應的分支名稱。

總結就是：把你本地分支 master (默認分支)推送到遠程的 master 分支（同樣也是新建倉庫時默認分支）
而使用 -u origin 就是建立上游關系，這樣以后推送代碼的時候，直接使用 git push 就可以啦，或者說以后拉取代碼的時候直接使用 git pull

但是！有些同學可能在這里遇到了問題！例如：

別擔心！這是因為我們剛才手動在Gitee那里手動刪除了 README.md 這個文件，導致報錯說你還沒有拉取最新的更新，那我們直接按照它的提示操作：git pull

但是又出現問題了！git提示你不是在master分支上，那就按照它的提示去操作

git branch --set-upstream-to=origin/master master

執行這段指令的意思就是確立本地 master 分支與遠程倉庫中 origin 倉庫的 master 分支之間的跟蹤關系，以便在推送和拉取代碼時更方便地進行同步操作。

其實如果沒有剛才的演示操作，只要執行到git push -u origin master就完成了

這時候我們已經真正設置好了跟遠程分支的連接，那就讓我們再拉取一次遠程分支內容！

git pull --allow-unrelated-histories

那為什么要加--allow-unrelated-histories呢，因為本地分支跟遠程分支沒有共同提交的歷史，加上后就允許合并歷史，因為遠程分支沒有任何內容所以不用擔心會出現沖突或者問題。

那我們再去提交一次代碼！

git push -u origin master

這樣就表示已經推送成功了！

那我們在遠程倉庫可以看到你剛才提交的代碼了！

再溫馨提示一次：如果沒有剛才的演示操作（手動在gitee新增/刪除/改動文件）就不會出現這些報錯問題，所以遇到報錯不要慌，基本按照Git提示就能解決！

.gitignore文件的作用

在剛才的項目文件中，細心的同學可以發現，有.gitignore文件的存在，而.gitignore文件是git也是很重要的部分，主要用于忽略某些文件/目錄的更改、提交等。

例如你是一個前端開發人員，你也不想你的依賴包 node_modules 提交到遠程倉庫吧？因為如果把依賴也提交到遠程，這樣一是會導致提交文件過大，會導致提交失敗，以及每次改動git都會遍歷node_modules目錄下的所有文件，導致效率極其緩慢。這時候我們可以通過編輯 .gitignore文件讓Git在保存提交的時候忽略某些文件/目錄，達到過濾的效果。
如何在 Git 中忽略一個文件和文件夾
如果你想只忽略一個特定的文件，你需要提供該文件在項目根目錄下的完整路徑。

例如，如果你想忽略位于根目錄下的 text.txt 文件，你可以做如下操作：

/text.txt

而如果你想忽略一個位于根目錄下的 test 目錄中的 text.txt 文件，你要做的是：

/test/text.txt

你也可以這樣寫上述內容：

test/text.txt

如果你想忽略所有具有特定名稱的文件，你需要寫出該文件的字面名稱。

例如，如果你想忽略任何 text.txt 文件，你可以在 .gitignore 中添加以下內容：

text.txt

在這種情況下，你不需要提供特定文件的完整路徑。這種模式將忽略位于項目中任何地方的具有該特定名稱的所有文件。

要忽略整個目錄及其所有內容，你需要包括目錄的名稱，并在最后加上斜線 /：

test/

這個命令將忽略位于你的項目中任何地方的名為 test 的目錄（包括目錄中的其他文件和其他子目錄）。
需要注意的是，如果你只寫一個文件的名字或者只寫目錄的名字而不寫斜線 /，那么這個模式將同時匹配任何帶有這個名字的文件或目錄：

# 匹配任何名字帶有 test 的文件和目錄
test

如果你想忽略任何以特定單詞開頭的文件或目錄怎么辦？
例如，你想忽略所有名稱以 img 開頭的文件和目錄。要做到這一點，你需要指定你想忽略的名稱，后面跟著 * 通配符選擇器，像這樣：

img*

這個命令將忽略所有名字以 img 開頭的文件和目錄。

但是，如果你想忽略任何以特定單詞結尾的文件或目錄呢？
如果你想忽略所有以特定文件擴展名結尾的文件，你需要使用 * 通配符選擇器，后面跟你想忽略的文件擴展名。

例如，如果你想忽略所有以 .md 文件擴展名結尾的 markdown 文件，你可以在你的 .gitignore 文件中添加以下內容：

*.md

這個模式將匹配位于項目中任何地方的以 .md 為擴展名的任何文件。

在實際前端項目中可能會忽略以下這些目錄/文件（根據實際情況自行編寫）

node_modules/
dist/
.vscode

不同分支作用

在說場景之前，我們先簡單了解一下不同分支的作用。在本地開發中，可能會出現不同分支從而應對不同的場景作用。

本地分支：

master: 默認主分支，是生產環境分支，在本地開發中基本不會改動。

dev: 默認開發分支，是開發環境分支，在本地開發中基本不會在該分支上直接改動，主要用于拉取遠程最新代碼，以及合并其他分支代碼。

數字分支：需求分支，開發環境分支。在實際開發中，我們需要根據不同需求去切換不同的分支，這樣就能保持需求代碼的獨立，就算做不完這個需求也不會影響主分支的代碼。有時也用于修改該需求的Bug

個人命名分支：開發環境分支。在實際開發中，你想在這個項目做一些暫時不能影響主分支的代碼測試。或者臨時修改bug

hotfix:臨時緊急修復分支，正式環境分支。比如你代碼已經上線了，但是臨時發現了Bug，必須立馬修改，該分支就起到了作用。

遠程分支：

master 、 dev 、hotfix ，以及可能出現的其他分支…

下面我會根據實際場景去分析這些分支的作用。

場景2：多人開發怎么去劃分分支

假設我們已經有了Gitee遠程倉庫,用 git clone 指令克隆代碼到本地后，這時候要注意，就算遠程倉庫存在多分支情況（master 、 dev 、hotfix），我們克隆下來的是默認在master分支的，以及克隆下來的是代碼目錄。

在我們關閉Git Bash后，重新打開就可以看到你所在分支

因為我們目前的遠程分支只有master，我們需要在本地切換到dev分支，使用以下指令

git checkout -b dev

git checkout -b dev 是用于創建一個新的分支并切換到該分支上。讓我們來解釋這個命令：

git checkout: 通常用于切換分支。
-b dev: 這是 git checkout 命令的一個選項，-b 的意思是創建并切換到一個新的分支。dev 是新分支的名稱，在這里是你指定的分支名。

綜合起來，git checkout -b dev 的意思是：

如果本地已存在名為 dev 的分支，則會切換到 dev 分支。
如果本地不存在名為 dev 的分支，則會創建一個名為 dev 的新分支，并將當前工作目錄切換到這個新分支上。

相當于把 master 分支上的所有內容拷貝到 dev 分支上，但相互獨立，這樣你就可以在dev分支上進行一些代碼操作（不建議直接修改dev分支）

那我們的個人分支呢？例如用你的名字縮寫（這里用cpc為例），那我們可以繼續創建一個 cpc 分支并切換到該分支。

git checkout -b cpc

值得注意的是，你從哪個分支上開始創建分支的，它就把你那個分支上的內容拷貝一份并切換到你新建的分支。所以剛才的操作相當于：把dev上的所有內容拷貝到新的cpc分支，這時候cpc分支的內容跟dev內容是一樣的！

好，這時候我們已經創建好屬于你自己的個人本地分支，注意是本地。這時候我們可以隨意修改代碼了，例如修改 README.md 文件

在你修改完并保存后，就想推送到遠程倉庫，剛才我們提到，一般來說遠程倉庫為了方便管理，只會存在一些重要分支（master、 dev、hotfix以及其他分支），那我們現在遠程還沒有dev分支，就讓我們來創建一個吧~

在你的cpc分支上更改完代碼后，就需要保存并提交到你的本地Git倉庫，

git add .
git commit -m '修改了md文件'

可以看到在輸入完 git commit -m '修改了md文件'后，Git輸出了： 1 file changed，這是因為我們剛才只修改了一個文件也就是md文件。做完以上操作后我們就完成了：暫存所有文件并提交到了本地的cpc分支倉庫。

合并代碼

因為dev分支是我們生產環境的主分支，所以我們在更改代碼后就需要把這些代碼合并到dev分支并提交到遠程倉庫

因為已經在cpc分支上提交到了本地倉庫，我們就可以切換到本地的dev分支（記住一定要先暫存提交！）

git checkout dev

有些同學可能疑問，為什么這時候不需要加-b了呢，這是因為-b是新建分支，但是我們本地剛才已經創建過了dev分支，直接切換即可

可以看到我們正常切換到了dev分支，同時打開文件，可以看到dev分支的內容還是原來的。

那我們可以使用 git merge cpc 指令把cpc分支修改的內容合并到dev分支

git merge cpc

如果出現以上輸出，說明已經合并成功，并提示哪個文件做了修改。那我們再去看一下文件：

合并成功！ 說明你已經成功把cpc修改的內容合并到了dev分支。

提交代碼到遠程

既然我們已經把代碼改完并合并到本地的dev分支了，我們就要把dev分支上的內容提交到遠程倉庫。這樣其他成員使用的時候就會能看到最新的代碼。
我們使用 git push 去推送代碼

git push

出錯了！ 但是別慌，這是因為我們遠程倉庫并沒有dev分支，那我們設置一下關聯不就好了

要解決這個問題，可以按照提示的建議執行以下命令：

git push --set-upstream origin dev

這條命令的含義是：

git push: 嘗試將當前分支的更改推送到遠程倉庫。
--set-upstream origin dev: 設置當前分支 dev 的遠程跟蹤分支為 origin/dev，這樣之后執行 git push 或 git pull 時就不需要再指定遠程分支了。

執行這條命令后，Git 將會將本地的 dev 分支與遠程倉庫的 dev 分支關聯起來，之后可以直接使用 git push 和 git pull 命令，Git 將自動使用正確的遠程分支進行操作。

OK，推送成功！ 我們再去Gitee上看看：

我們已經成功創建了遠程分支。那我們再去看看dev分支下找到md文件，可以看到我們修改的內容！ 這樣遠程倉庫的dev分支就有了最新的代碼！

那如果我遠程倉庫已經有dev分支了怎么辦？

好，現在假設我們要重新克隆該項目，克隆完并關掉 Git Bash 窗口并再次打開

重新打開后，可以看到我們默認是在master，因為遠程已經有了dev分支，我們直接用 git checkout dev 切換到dev分支即可。

場景3：多人開發，不同需求分支管理

假如某天領導給開發AAA跟開發BBB分別布置了一些需求任務，正常操作流程應該是：根據需求編號（例如001、002）去創建本地分支。

假設開發AAA今天要做001需求，那他就得從dev分支拉取最新代碼，然后新建分支并切換到新分支，這里要注意的是從dev分支切換，這是因為需要先拉取最新代碼，并把dev分支代碼拷貝到001分支。這樣到時候改完合并代碼時能大大減少沖突概率。

前置條件：如果處于非dev分支，例如在剛才的個人分支cpc分支，并做了代碼修改怎么辦？

這是初學者可能會經常遇到的問題，突然領導給你加了一個需求或新出現一個bug，但是你已經在個人分支或其他分支上做了代碼修改操作。那這時候該怎么辦呢？

那就需要先暫存到當前本地分支，再切換到dev分支，注意！這里只是切換不是合并，相當于你保存了cpc分支，等有空了再回來完善，臨時切換到dev分支，兩個分支相互獨立！

git stash

具體來說，git stash 的作用是：

保存工作進度：將你的當前工作目錄和暫存區中的修改保存起來，以便稍后恢復使用。
清空工作目錄：將當前工作目錄的狀態重置為最近的提交狀態，即沒有任何未提交的修改。

在保存完當前分支后，我們就可以正常切換回dev分支了

如果你沒有上述的前置條件，本身就處于在dev分支，那就直接拉取最新代碼并新建分支即可

git pull
git checkout -b 001

可以看到我們已經處于最新代碼的001分支，這時候我們就可以去完成001需求啦

代碼沖突

代碼沖突主要是出現在代碼合并階段，那我們來思考一下以下三種情況哪種會發生沖突？

兩個人對同一項目的不同文件進行了修改
兩個人對同一項目的同一文件的不同區域進行了修改
對同一項目的同一文件的同一區域進行了不同修改

答案就是：第三種！前面兩種Git會自動幫我們合并代碼，而第三種是需要我們手動去合并

問題1：什么是自動合并呢？

合并本質上可以理解為將兩個人（分支）對項目的修改整合到一塊，注意是對項目的修改。上述三種情況的前兩種是兩個人對項目的不同區域進行修改，互不干擾，所以Git可以自動的將兩個人對項目的修改整合到一起

問題2：什么是手動合并呢？

當Git不知道該保留兩個修改中的哪一個時，就需要手動來進行這個決策，可以選擇保留兩個修改中的任意一個，或是選擇將兩個修改全部保留。完成上述決策就是手動合并的目的。

問題3：為什么需要手動合并？

當可以自動合并時，說明兩個人的修改不會沖突，但是當兩個人對同一文件的同一區域進行了修改那么這兩個修改就會產生沖突，Git將無法整合這兩個修改，因為Git不知道它該保留兩個修改中的哪一個（或是要一并保存），這是就需要人工進行手動合并了。

場景4：在你修改了A文件某行代碼，但是你另一個同事也修改了A文件該代碼，他比你先提交到了遠程的`dev`分支，這時你在`001`分支已經寫完了需求，并進行了`git add .` 跟 `git commit -m '修改A文件'`，現在切換回`dev`分支，然后執行了一次`git pull`，發現有更新，這時候你需要把`001`分支內容合并到`dev`，你開始操作：`git merge 001` ，發現報錯了！

# 處于001分支
git add .
git commit -m '修改了A文件'# 切換回dev分支
git checkout dev
# 拉取最新更新
git pull# 把001分支內容合并到dev
git merge 001

借用網上的圖進行展示

出現類似以下信息說明 _config.yml文件有沖突。這時候就可以打開_config.yml

打開文件我們可以看到沖突的內容，例如：

<<<<<<<HEAD hello world 001 ======= hello world dev >>>>>> dev

關于怎么手動解決只需要手動點擊選擇即可，在解決完所有的文件沖突后，我們可以進行保存文件并提交到遠程倉庫。

git add . 
git commit -m "合并了_config.yml文件" 
git push

這時候我們就可以成功解決了合并沖突！

場景5：開發到一半，卻需要切換分支

實際開發中，可能常常遇到bug以及臨時需求，你可能專注于某些代碼中，已經做了很深度的修改，這時候領導讓你要緊急處理這個問題。其實跟我們剛才場景3的前置條件一樣。所以我一直強調的是，不要直接在master/dev分支上直接操作代碼，保證這兩個主分支的干凈歷史。

所以我們無論是測試代碼，還是新需求，又或者修改bug，都需要切到單獨分支上去操作。

測試代碼：
可以切換到你的個人分支（例如cpc分支上），又或者從dev分支新建一個單獨測試分支。
新需求： 可以以需求編號為分支名，從dev分支上新建單獨數字分支
修改bug： 如果是獨立bug，需要從dev分支上新建bug分支進行修改，修改完再合并到dev

如果是臨時處理問題，則需要像前置條件流程一樣處理，需要先暫存到當前本地分支，再切換到dev分支，注意！這里只是切換不是合并，等有空了再回來完善，臨時切換到dev分支，兩個分支相互獨立！

git stash
git pull
git checkout -b 新分支

細心的同學可以注意到，我在創建新分支之前都會git pull一次，這是為了確保dev分支上的代碼是最新狀態。同時注意的是，你可能在完成你的需求同時別人已經提交了代碼到遠程倉庫了，所以dev分支在合并其他分支之前也要進行一次git pull

場景6：代碼經過測試后，需要發布到正式環境

前面我們已經提到master的作用主要是用于生產環境（部分公司為了省事可能直接使用dev分支做正式環境代碼，反正是兩套服務）。那我們就需要把dev分支上的代碼合并到master分支，并推送到遠程。

# 在dev分支上拉取最新的遠程dev代碼
git pull# 切換到master分支
git checkout master# 拉取最新master代碼
git pull# 合并dev
git merge dev# 推送到遠程master
git push

在該過程中一般合并代碼不會出現沖突，如果出現按照上面的解決方法解決即可，這時候我們就能確保遠程的master分支的代碼是全新的了。、

當然還有一個更省事的辦法就是直接使用dev分支的代碼。只要正確使用是不會出現問題的。

場景7：正式環境代碼出現緊急Bug,需要臨時修復

這可能是會出現的問題，而這時候就要一個 hotfix 熱修復分支，主要是操作步驟：

切換到master分支并拉取最新代碼

git checkout master
git pull

需要從master新建一個熱修復分支并加以版本號，如：v-1.0.0-hotfix ，常用于快速修復生產環境中的緊急 bug 或問題，其主要作用是在不影響正在開發的主分支或其他功能分支的情況下，快速地修復生產環境中的問題。

# 新建并切換到熱修復分支
git checkout -b v-1.0.0-hotfix

在v-1.0.0-hotfix分支上修復完bug后，需要合并到線上分支master，并推送

# 假設已經修復完bug
git add .
git commit -m '臨時修復bug:v-1.0.0'# 切換回master分支
git checkout master# 合并熱修復分支的內容
git merge v-1.0.0-hotfix
# 推送到master遠程分支
git push

這樣就能進行臨時修復了，但是也要注意把臨時修復的內容合并到dev分支

# 切換回dev分支
git checkout dev# 合并熱修復分支的內容
git merge v-1.0.0-hotfix
# 推送到dev遠程分支
git push

如果出現合并沖突，同樣的解決方法即可。（以上版本號可根據實際情況自定）

其他常用指令

看到這里，其實上面7種場景基本上能覆蓋實際項目開發中的各種情況，可以看到用到最多的其實就是那幾個指令：

# 暫存所有文件
git add .
# 提交修改到本地倉庫
git commit -m 'xxx'
# 暫存所有文件到倉庫，方便后續繼續修改
git stash
# 切換到指定分支
git checkout <branch>
# 拉取更新
git pull
# 推送代碼
git push

這些指令作用也做了詳細說明，包括出現的一些特殊情況的應對方法。

那再介紹幾個可能會常用到的指令

# 列出所有本地分支
git branch# 列出所有遠程分支
git branch -r# 列出所有本地分支和遠程分支
git branch -a# 放棄當前分支所有修改
git checkout .# 刪除分支
git branch -d [branch-name]# 刪除遠程分支
git push origin --delete [branch-name]
git branch -dr [remote/branch]