一、上傳本地項目到gitLab
1.先記錄個人信息
git config --global user.name "xxx"
git config --global user.email "xxx@xxx"
2.上傳
// 1. git add : 添加到暫存區
git add xxx文件
git add -A // 添加所有文件（通常改動較多可以直接使用這句命令）
// 2. git commit -m "備註信息"：添加到數據倉儲
git commit -m "備註信息" // 添加 -m 選項，將提交信息與命令放在同一行
git commit -a -m "備註信息"// 加上 -a 選項，就會自動把所有已經跟蹤過的文件暫存起來一併提交，從而跳過 git add 步驟（但是未經過git add步驟的新增的文件，就不可以，需要先git add）
// 3. git push 推送到遠程服務器 gitLab
git push [地址] master
// 推送本地分支到遠程
git push origin <分支名>
git status // 顯示工作目錄和暫存區的狀態
// 可以看見，執行 git add 前後的狀態對比
二、下載遠程服務器的項目到本地
1.將其他倉庫克隆到本地
包括被clone倉庫的版本變化
git clone <版本庫的url>
// HTTPS
git clone https://github.com/tensorflow/tensorflow.git
// SSH
git clone [email protected]:tensorflow/tensorflow.git
// 如果本地目錄不想與遠程倉庫同名:
git clone <版本庫的網址> <本地目錄名>
2.拉取遠程分支更新到本地倉庫
比如遠程倉庫裏的學習資料有了新內容，需要把新內容下載下來的時候，就可以使用git pull命令。事實上，git pull是相當於從遠程倉庫獲取最新版本，然後再與本地分支merge（合併）。
即：git pull = git fetch + git merge
注：git fetch不會進行合併，執行後需要手動執行git merge合併，而git pull拉取遠程分之後直接與本地分支進行合併。更準確地說，git pull是使用給定的參數運行git fetch，並調用git merge將檢索到的分支頭合併到當前分支中。
git pull <遠程主機名> <遠程分支名>:<本地分支名> // 使用
// 舉例：將遠程主機origin的master分支拉取過來，與本地的 master 分支合併。
git pull origin master
以上的git pull操作如果用git fetch來表示：
git fetch origin master:tmp // 本地新建temp分支，並將遠程的master分支下載到temp
git diff tmp // 可以比較本地代碼與剛剛從遠程下載下來的代碼的區別
git merge tmp // 合併temp分支到本地的master分支
git branch -d temp // 最後可刪除temp分支
三、本地分支的創建、切換、刪除
1.查看分支信息
git branch // 查看本地分支
git branch -r // 查看遠程分支
git branch -a // 查看所有分支（本地+遠程），只有分支名稱
git branch -v -a // 查看所有分支，有分支名稱+備註信息
2.新建分支，並切換到新的分支
git checkout -b develop
// 相當於下面兩步：
git branch develop // 創建 develop
git checkout develop // 切換到 develop
問：如何切換分支而又不用帶上剛剛修改的文件？
在使用 git 的時候，我們往往使用 branch 解決任務切換問題，例如，我們往往會建一個自己的分支去修改和調試代碼，如果發現原有的分支上有個不得不修改的 bug，我們往往會把完成一半的代碼 commit 提交到本地倉庫，然後切換分支去修改bug，改好之後再切換回來。這樣的話往往 log 上會有大量不必要的記錄。
其實如果我們不想提交完成一半或者不完善的代碼，但是卻不得不去修改一個緊急 Bug，那麼使用' git stash ' 命令就可以將你當前未提交到本地（和服務器）的代碼推入到 Git 的棧中，這時候你的工作區間和上一次提交的內容是完全一樣的，所以你可以放心的修 Bug，等到修完 Bug，提交到服務器上後，再使用 ' git stash apply ' 將以前一半的工作應用回來。
也許有的人會說，那我可不可以多次將未提交的代碼壓入到棧中？答案是可以的。當你多次使用 'git stash' 命令後，你的棧裏將充滿了未提交的代碼，這時候你會對將哪個版本應用回來有些困惑。
git stash list // 將當前的 Git 棧信息打印出來
git stash apply stash@{1} // 應用指定版本的工作 stash@{1}
git stash drop stash@{1} // 移除指定版本
git stash clear // 清空棧信息
3.合併分支
3.1 修改文件後，保存修改
git commit -a -m "修改一些細節" // 自動把所有已經跟蹤過的文件暫存起來一併提交
3.2 轉換到master，合併develop
// 切換到 master分支
git checkout master
// 對 develop 分支進行合併
git merge --no-ff develop // --no-ff 執行正常合併
解釋一下 --no-ff 參數。默認情況下，Git執行"快進式合併"（fast-farward merge），會直接將Master分支指向Develop分支
使用--no-ff參數後，會執行正常合併，在Master分支上生成一個新節點。爲了保證版本演進的清晰，我們希望採用這種做法。
- git merge –no-ff 可以保存你之前的分支歷史。能夠更好的查看 merge歷史，以及branch 狀態。
- git merge 則不會顯示 feature，只保留單條分支記錄
3.3 查看未合併工作的分支
git branch --no-merged
4.刪除分支 -d
git branch -d <branchName>
5.修改分支名稱
// 5.1 修改本地分支名
git branch -m oldName newName
// 5.2 修改遠程分支名 (已經推送遠程-假設本地分支和遠程對應分支名稱相同)
// a. 重命名遠程分支對應的本地分支
git branch -m oldName newName
// b. 刪除遠程分支
git push --delete origin oldName
// c. 上傳新命名的本地分支
git push origin newName
// d.把修改後的本地分支與遠程分支關聯
git branch --set-upstream-to origin/newName
四、遠程分支
1.查看遠程分支
git branch -r // git branch 是查看本地分支； git branch -a 是查看所有分支
// 要先 git pull 遠程的最新信息，才能看到最新的所有遠程分支
2.跟蹤遠程分支
2.1 查看本地分支與遠程分支的對應關係
git branch -vv //查看設置的所有跟蹤分支，可以使用 git branch 的 -vv 選項。 這會將所有的本地分支列出來並且包含更多的信息，如每一個分支正在跟蹤哪個遠程分支與本地分支是否是領先、落後或是都有。
git branch -v -a // 顯示當前使用倉庫的所有分支
git remote show origin // 查看本地分支與遠程分支的對應關係
2.2 如果遠程新建了一個分支，本地沒有該分支，可以用：
git checkout --track origin/branch_name // branch_name 是遠程需要跟蹤的分支名
2.3 拉取遠程分支，並創建本地分支（作用和上面 好像一樣）
git checkout -b 本地分支名x origin/遠程分支名x
用上面中方法，得到的分支名永遠和遠程的分支名一樣。如果想新建一個本地分支不同名字，同時跟蹤一個遠程分支可以利用。
git checkout -b new_branch_name branch_name
小結：
git push --set-upstream origin branch_name // 在遠程創建一個與本地 branch_name 同名的分支並跟蹤
git checkout --track origin/branch_name // 在本地創建一個與遠程 branch_name 同名分支跟蹤遠程分支
從遠程分支 checkout 出來的本地分支，稱爲 跟蹤分支 (tracking branch)。跟蹤分支是一種和某個遠程分支有直接聯繫的本地分支。在跟蹤分支裏輸入 git push，Git 會自行推斷應該向哪個服務器的哪個分支推送數據。同樣，在這些分支裏運行 git pull 會獲取所有遠程索引，並把它們的數據都合併到本地分支中來。
也就是說，如果存在跟蹤分支 originTest ，在該分支上修改文件，然後直接執行 git push ，那麼修改的文件存在遠程的 originTest 分支中。
3.刪除遠程分支
git push origin --delete <遠程分支名> // 刪除後可以通過 git branch -r 查看所有遠程分支
4.根據遠程已刪除的分支，刪除本地還沒刪除的分支
可以通過命令 git branch –a 用來查看所有的分支，包括本地和遠程的。但是有時會發現有些分支在遠程早就被刪除了，但是本地依然可以看見這些被刪除的分支。
可以通過命令，git remote show origin 來查看有關於origin的一些信息，包括分支是否tracking。
refs/remotes/origin/feature/basis-group 過時（使用 'git remote prune' 來移除）
refs/remotes/origin/release/5.1.1 過時（使用 'git remote prune' 來移除）
develop 推送至 develop (最新)
master 推送至 master (最新)
此時刪除本地過時的分支：git remote prune origin
git remote prune origin
> [已刪除] origin/feature/basis-group
> [已刪除] origin/release/5.1.1
五、臨時（feature, release, hotfix）分支
1.概念
前面講到版本庫的兩條主要分支：Master和Develop。前者用於正式發佈，後者用於日常開發。其實，常設分支只需要這兩條就夠了，不需要其他了。
但是，除了常設分支以外，還有一些臨時性分支，用於應對一些特定目的的版本開發。臨時性分支主要有三種：
- 功能（feature）分支
- 預發佈（release）分支
- 修補bug（fixbug）分支
這三種分支都屬於臨時性需要，使用完以後應該刪除，使得代碼庫的常設分支始終只有Master和Develop。
2.功能分支 feature
是爲了開發某種特定功能，從Develop分支上面分出來的。開發完成後，要再併入Develop。功能分支的名字，可以採用 feature-* 的形式命名。
3.預發佈 release
我們最初所有的開發工作都在 develop 分支上，當我們這一期的功能開發完畢的時候，我們基於 develop 分支開一個新的 release 分支。這個時候我們就可以對 release 分支做統一的測試了，另外做一些發佈準備工作：比如版本號之類的。
如果測試工作或者發佈準備工作和具體的開發工作由不同人來做，比如國內的 RD 和 QA，這個 RD 就可以繼續基於 develop 分支繼續開發了。再或者說公司對於發佈有嚴格的時間控制，開發工作提前並且完美的完成了，這個時候我們就可以在 develop 分支上繼續我們下一期的開發了。同時如果測試有問題的話，我們將直接在 release 分支上修改，然後將修改合併到 develop 分支上。
待所有的測試和準備工作做完之後，我們就可以將 release 分支合併到 master 分支上，並進行發佈了。
4.緊急修復 hotfix
顧名思義，hotfix 分支用來修復線上 bug。當線上代碼出現 bug 時，我們基於 master 分支開一個 hotfix 分支，修復 bug 之後再將 hotfix 分支合併到 master 分支並進行發佈，同時 develop 分支作爲最新最全的代碼分支，hotfix 分支也需要合併到 develop 分支上去。仔細想一想，其實 hotfix 分支和 release 分支功能類似。hotfix 的好處是不打斷 develop 分支正常進行，同時對於現實代碼的修復貌似也沒有更好的方法了（總不能直接修改 master 代碼吧:D）。
注意：如果在拉 feature 時，別人有個release在測試，那麼先別開feature。因爲兩者都是根據develop拉下來的，如果別人release沒通過，而我的feature通過測試，後面上線後就包含了之前release沒通過的代碼。解決方法：應該自己拉 hotfix，驗收後MR時，標題前加上“WIP”（避免 MR 在準備就緒前被合併），在確認可以合併後，則編輯工單來手動刪除WIP。
六、pull、rebase、merge
當你在專用分支上開發新 feature 時，然後另一個團隊成員在 master 分支提交了新的 commits，這會發生什麼？這會導致分叉的歷史記錄，對於這個問題，使用 Git 作爲協作工具的任何人來說都應該很熟悉。
整體概括：
git fetch // 從遠程下載到本地；若需要合併還需要 merge 合併。
git pull // 從遠程下載到本地，併合併到當前分支
git rebase // 在新基準的基礎上，將本地基於舊基準的commits再做一遍
1.git pull
git pull：從遠程獲取當前分支的最新更改，並將這些更改應用於分支的本地副本。通常，這是通過合併完成的，即將本地更改合併到遠程更改中。因此 git pull = git fetch & git merge
git pull 和 git pull --rebase 區別：git pull做了兩個操作分別是 獲取 和 合併。所以加了rebase就是以rebase的方式進行合併分支，默認爲merge。
2.git rebase
git rebase 解決了和 git merge 同樣的問題。這兩個命令都旨在將更改從一個分支合併到另一個分支，但二者的合併方式卻有很大的不同。
可以使用以下命令將 master 分支合併到 feature分支上：
git checkout feature // 切換到 feature 分支
git rebase master // 合併 master 分支
這裏補充一點：rebase 做了什麼操作呢？
- 首先，git 會把 feature 分支裏面的每個 commit 取消掉；
- 其次，把上面的操作臨時保存成 patch（補丁） 文件，存在 .git/rebase 目錄下；
- 然後，把 feature1 分支更新到最新的 master 分支；
- 最後，把上面保存的 patch 文件應用到 feature1 分支上。
將整個 feature 分支移動到 master 分支的頂端，從而有效地整合了所有 master 分支上的提交。但是，與 merge 提交方式不同，rebase 通過爲原始分支中的每個提交創建全新的 commits 來 重寫 項目歷史記錄。
在rebase的過程中，有時也會有conflict，這時Git會停止 rebase 並讓用戶去解決衝突，解決完衝突後，用 git add 命令去更新這些內容，然後不用執行git-commit，直接執行 git rebase --continue ，這樣 git會繼續應用餘下的補丁。
在任何時候，都可以用 git rebase --abort 參數來終止rebase的行動，並且 feature1 分支會回到rebase開始前的狀態。
3.git merge
最簡單的方式是通過以下命令將 master 分支合併到 feature 分支中：
git checkout feature
git merge master
// 後綴 --no-f ：如果不加 --no-ff 則被合併的分支之前的commit都會被抹去，只會保留一個解決衝突後的 merge commit；加了就會保留
或者，你可以將其濃縮爲一行命令：
git merge feature master
這會在 feature 分支中創建一個新的 merge commit，它將兩個分支的歷史聯繫在一起，請看如下所示的分支結構：
使用 merge 是很好的方式，因爲它是一種 非破壞性的 操作。現有分支不會以任何方式被更改。這避免了 rebase 操作所產生的潛在缺陷。
另一方面，這也意味着 feature 分支每次需要合併上游更改時，它都將產生一個額外的合併提交。如果master 提交非常活躍，這可能會嚴重污染你的 feature 分支歷史記錄。儘管可以使用高級選項 git log 緩解此問題，但它可能使其他開發人員難以理解項目的歷史記錄。
4. 整體流程：
1. 前提：遠程上線，本地需要更新
2. 本地拉取最新master和develop
git pull <遠程主機名> <遠程分支名>:<本地分支名>
git pull origin master:master
git pull origin develop:develop
3. 切換到自己的開發分支，rebase 分支 develop / master
git rebase develop
4. 順利的話就會直接完成，有衝突的話就需要依個解決衝突
4.1 當遇到衝突
依次解決衝突後，使用：
git add/rm <conflicted_files> // 添加進暫存區或刪除文件
git rebase --continue // 繼續執行 rebase
5. 完成rebase後，繼續開發。然後執行git push -f origin feature/add-activeIndex 把本地分支覆蓋遠程分支
6.介紹一下 git rm
- git rm： 來刪除文件，同時還會將這個刪除操作記錄下來;
- rm： 來刪除文件，僅僅是刪除了物理文件，沒有將其從 git 的記錄中剔除;
提示：即使你已經通過 rm 將某個文件刪除掉了，也可以再通過 git rm 命令重新將該文件從 git 的記錄中刪除掉。
注意：上述操作最後要執行git commit才真正提交到git倉庫
- git rm ： 同時從工作區和索引中刪除文件。即本地的文件也被刪除了。
- git rm --cached ： 從索引中刪除文件。但是本地文件還存在， 只是不希望這個文件被版本控制。
七、查看倉庫的歷史記錄
1.git log
git log // 顯示倉庫中每個 commit 的詳細提交信息
--oneline // 每行顯示一個 commit；顯示 commit 的 SHA 的前 7 個字符；顯示 commit 的備註消息
--graph // 開啓了拓撲圖選項
--reverse // 逆向顯示所有日誌
--stat // 顯示被修改的文件；顯示添加/刪除的行數；顯示一個摘要，其中包含修改/刪除的總文件數和總行數
--patch // 簡寫爲 -p；顯示具體的修改
-n // 顯示n條
// 這些選項可多選
git log SHA // SHA 是某一個commit的哈希值；查看特定的commit
// 常用
git log --oneline -5 // 只需要看前幾條記錄的情況下
太多log記錄時，可以按回車鍵查看下一個，可以按 q 退出查看
2.git show
git show SHA // 顯示特定的提交信息
// 與 git log SHA 的區別：
git log SHA：並不會單獨的顯示某個提交，而是輸出這條數據從最開始到最新狀態的歷史記錄（commit頭信息、作者、日期、commit備註消息）
git show SHA：顯示commit頭信息、作者、日期、commit備註消息、具體文件差異
八、版本回退 git reset
1.介紹
實際操作時，每當覺得文件修改到一定程度時，就可以“保存一個快照” commit 。一旦你把文件改亂了，或者誤刪了文件，還可以從最近的一個commit恢復，然後繼續工作，而不是把幾個月的工作成果全部丟失。具體操作：1.查看歷史提交記錄（ git log ）；2.回退到指定的 commit。
git reset HEAD^ // 回退到上一版本
git reset HEAD～1 // 回退到上一版本
git reset HEAD～100 // 回退到前100個版本
如果從版本 1.1.5 回到 1.1.0，但是還想再回去 1.1.5 ，那麼就找到之前git log 的信息，找到該版本的 commit SHA，就可以 git reset SHA 回去。如果找不到之前的信息了，則可以通過命令 git reflog 查找。（git reflog 是記錄每一次命令的）
Git的版本回退速度非常快，因爲Git在內部有個指向當前版本的HEAD指針，當你回退版本的時候，Git僅僅是把 HEAD 指向改變了而已。reset做的事就是：重置HEAD(當前分支的版本頂端）到另外一個commit，這不會產生commits，僅僅更新一個branch。
2.參數
2.1 --soft
- git reset --soft：回退到某個版本，只回退了commit的信息，不會恢復到index file一級。如果還要提交，直接commit即可； // 也就是：只有最新的commit操作被撤銷，但代碼沒有撤銷；如果還想要再次提交，再次 commit 即可。
2.2 --hard
- git reset --hard：徹底回退到某個版本，本地的源碼也會變爲上一個版本的內容，撤銷的commit中所包含的更改被沖掉；
3.其他 git revert
git revert // 創建一個commit來覆蓋當前的commit，指針向後移動
區別：
- git revert 是撤銷某次操作，此次操作之前的commit都會被保留
- git reset 是撤銷某次提交，但是此次之後的修改都會被退回到暫存區
九、遠程倉庫 git remote
1.查看遠程倉庫
git remote // 顯示遠程倉庫名稱 origin
git remote -v // 顯示需要讀寫遠程倉庫使用的 Git 保存的簡寫與其對應的 URL
// origin [email protected]:liyapei/todolist.git (fetch) // 讀
// origin [email protected]:liyapei/todolist.git (push) // 寫
2.添加遠程倉庫
git remote add <shortname> <url> // git remote add vuecli https://github.com/Allison-LYP/vuecli3-project.git
3.遠程倉庫的重命名、移除、修改地址
3.1 重命名
git remote rename <oldName> <newName> // 1.重命名
// git remote rename vuecli vc 注意：這同樣也會修改你的遠程分支名字。 那些過去引用 vuecli/master 的現在會引用 vc/master
3.2 移除遠程倉庫
git remote rm <遠程倉庫名> // 2.移除
3.3 修改遠程倉庫地址
git remote set-url <遠程倉庫名> url // 3.修改遠程倉庫地址(修改完通過 git remote -v 查看改變了)
// git remote set-url vc https://github.com/Allison-LYP/vuecli3-project.git
十、標籤 git tag
1.打標籤
首先，先轉換到需要打標籤的分支上（ git checkout），完成相關的 commit 操作後，再打標籤。
git tag // 查看所有標籤
1.1 打一個新標籤
git tag -a 標籤名 -m "附註信息" // 命名格式
// git tag -a v0.1.0 -m "完成了文章a和文章b的撰寫，耗費時間2h"
1.2 想給之前的某一個 commit 打標籤
git tag -a 標籤名 -m "附註信息" commitID
// git tag -a v0.1 -m "version 0.1 released" 1094adb
注意：標籤總是和某個commit掛鉤。如果這個commit既出現在master分支，又出現在dev分支，那麼在這兩個分支上都可以看到這個標籤。
1.3 打標籤遵循語義化版本控制規範
版本格式：主版本號.次版本號.修訂號，版本號遞增規則如下：
- 主版本號：當你做了不兼容的 API 修改（大型的業務變動，或者技術架構改動）
- 次版本號：當你做了向下兼容的功能性新增（增加新功能、性能升級，或者重構原有某部分功能）
- 修訂號：當你做了向下兼容的問題修正（業務小改動，或者 Bug 修復等）
2.將tag推送至遠程倉庫
git push origin --tags
如果剛剛同步上去，就發現了一個致命bug，需要重新打版本：
2.1 刪除標籤
git tag -d 標籤名 // 1.只刪除了本地的tag
git push origin :refs/tags/標籤名 // 推送空的同名版本到線下，達到刪除線上版本的目標
// 這時本地和遠程的已經全部刪除
3. 查看標籤信息
git tag -ln // 顯示所有 tag 及其 commit 信息
git show v1.0 // 回滾版本時，我們需要根據標籤名查找相應的commit提交信息。git show 標簽名會列出指定的標籤信息，及詳細的提交信息
4.獲取遠程版本
git fetch origin tag <tagName>
十一、補丁 git format-patch
應用場景：
有兩個git庫（同一個git庫不同分支可以用cherry-pick），兩個git庫代碼是相關聯的，要有選擇的定期將其中一個git庫的修改merge到另外一個庫中。（把庫A的一部分代碼生成補丁，在庫B裏打入）
Git 提供了兩種補丁方案，一是用git diff生成的UNIX標準補丁.diff文件，二是git format-patch生成的Git專用.patch 文件。
- 通過 git diff 生成的文件不含有 commit 信息，可以指定文件生成 diff，也可以指定單個 commit， 多個 commit 生成 。
- 通過 git format-patch 生成的 .patch 文件 含有 commmit 信息。一個 commit 對應一個 patch 文件。
1.打補丁
1.1 某次提交（含）之前的幾次提交（往下算）
git format-patch <commit id> -n // n指從 commit id 對應的 commit 開始算起的 n 個提交
// eg: git format-patch da39747 -1 : da39747 本身
// eg: git format-patch da39747 -2 : 包含 da39747 的之前的2次提交（即 da39747 本身 + 他的前一個）
1.2 從某 commit 以來的修改（不包含該 commit ）（往上算）
git format-patch <commit id>
1.3 某兩次 commit 之間的所有 patch
git format-patch <commit id1> .. <commit id2>
1.4 獲取 commit id
git log --oneline
2.把補丁拷貝到目標git的目錄下（庫B）
即 補丁打完後，將其放到需要放到的項目目錄下。可以在項目下建一個 patch 文件夾，放置需要的 .patch 文件
3.測試patch
3.1 檢查patch文件
git apply --stat <patch文件名>
3.2 檢查是否能應用成功
git apply --check <patch文件名> // 沒顯示文字，就說明可用，且無衝突
3.3 打入patch
在使用git am之前， 你要首先git am --abort 一次，來終止以前的am信息，這樣纔可以進行一次全新的am
git am --s < xxx.patch // 使用--s或--signoff選項，可以commit信息中加入Signed-off-by信息
// 可以批量，也可以單個
// git am ~/patch/patch/*.patch patch文件放在這個路徑下
4.衝突解決
當我們打補丁出現衝突的時候，這個時候需要我們手動解決衝突。
4.1 首先，執行以下命令，自動合入 patch 中不衝突的代碼，同時保留衝突的部分
git apply --reject xxxx.patch // 會生成後綴爲 .rej 的文件，保存沒有合並進去的部分的內容
4.2 解決完衝突後刪除後綴爲 .rej 的文件，並執行 git add 添加改動到暫存區
第三步： 執行 git am --resolved 或者git am --continue ，最後 push 上去。
5.如何製作與使用PATCH
PATCH是指在ci編譯時用到的一個環境變量，變量名爲$AG_PATCH，ci執行編譯前會先應用該變量的內容。ci中關於PATCH的操作詳見項目中的.gitlab-ci.yml文件，搜索$AG_PATCH。PATCH的內容放在項目git頁面 -> 設置 -> CI/CD -> 環境變量。點擊下方的展示按鈕即可在"AG_PATCH"項的右側看到patch的內容，更改內容後點擊下方的保存按鈕即可保存。
(1）何時適合用打PATCH的方式上線
- 需要快速上線時。例如突發的bug，可以通過打PATCH緊急修復上線。
- 臨時性的改動，或短時間需要多次改動的地方。例如某個功能上線但暫時不開放、因某個活動開展需要網站進行調整、需要接入用於測試的數據分析產品。
(2)開發人員打PATCH的步驟
- 切換本地git項目的分支爲master
- 確保master爲最新。並確保當前工作區是乾淨的，無任何文件被修改，有修改的先用git stash暫存起來
- 從項目git頁面中複製PATCH內容，並在本地項目根目錄中新建文件，可命名爲patch.diff，將PATCH內容保存到該文件中
- 在編輯器中將patch.diff裏的所有$$替換爲$（注1）
- 在根目錄執行git apply patch.diff
- 此時可以對代碼進行本次打PATCH要做的改動
- 改動完成後在本地項目執行npm run test與npm run build以確認PATCH內容無誤
- 確認無誤後，在本地項目根目錄執行git diff > new-patch.diff，以此將本次的改動輸出到new-patch.diff中
- 用編輯器打開根目錄的new-patch.diff文件，將所有$替換爲$$
- 將new-patch.diff覆蓋項目git頁面ci變量中的AG_PATCH變量的內容，點擊下方的保存按鈕。此時即已完成PATCH變量的修改
- 此時在ci中重新編譯、部署即可將PATCH的改動上線
注1：因爲shell腳本中$是關鍵字，所以寫到PATCH中的$都需要轉成$$。相應的，執行git apply patch.diff去讀取PATCH之前需要將PATCH中的$$轉換成$。
十二、git cherry-pick
可以選擇某一個分支中的一個或幾個commit(s)來進行操作，對已經存在的commit 進行再次提交。比如 存在兩個分支，branch1和branch2。branch2上有幾個 commit 想要轉到 branch1 上，則進行操作。
// 1. 先確定 branch2 需要提交的 commit 的 id
// 2. 轉到分支 branch1 上
git checkout branch1
// 3. 將 commit 提交
git cherry-pick <commit id> // commit id 是 branch2 上的
如果順利，則正常提交；如果失敗，提示衝突，則手工解決：
git status // 看哪些文件出現衝突
命令集合：
git cherry-pick <commit id> // 單獨合併一個提交
git cherry-pick -x <commit id> // 同上，不同點：保留原提交者信息。
git cherry-pick <start-commit-id>..<end-commit-id> // cherry-pick一個區間的commit, ( start, end ]
git cherry-pick <start-commit-id>^..<end-commit-id> // [ start, end ]
實際應用
1. 如果git stash list有多個存儲的記錄，如果應用/丟棄某個特定的記錄
git stash apply stash@{1} // 應用指定版本的工作 stash@{1}
git stash drop stash@{1} // 移除指定版本
2. 以git flow release finish爲例，如何查看此命令有哪些後綴參數可用
命令行後面加後綴 -h
3. 接2，git flow release finish xxx，如何使用自定義tag messaage
git tag -ln // 回車備註後可以查看到
4. 在執行git add 操作之後，如何把暫存區的內容回退至工作區
git reset HEAD <fileName>
5. git rebase 完成之後，在遠程倉庫和本地倉庫commit記錄不一致的情況下，如何同步代碼
強制更新(將本地的更新到遠程)
git push origin <分支名> -f // 加個 -f後綴