---

Git常見命令

太常見的四件套 clone、pull、commit、push 就不說了。

1. 推送空提交

git commit --allow-empty -m "Empty-Commit"

然后push一下就OK了。

Q: why空提交？

A: 因為對于Github上面需要CI的項目，檢查流水線或者是CLA協議卡住了。第一種方法是手動重新構建流水線然后同時構建分支流水線。但是如果無法手動啟動構建，那么唯一的構建方法就是使用 Git。這時候你不需要做任何修改，只需要構建項目，所以需要推送一個空的提交來啟動構建。

---

2. 提交Clean-PR

【注意】 這是為了很大型項目開發過程中，覆蓋遠程舊分支以保持干凈的commit歷史，方便Review，但是此操作僅適用于個人分支，用在主分支的時候務必小心！！！

1. 添加上游倉庫并同步最新代碼

   git remote add upstream https://github.com/Echo-Nie/Demo.git
   git fetch upstream develop
   

2. 基于上游的develop創建新分支

   git checkout -b clean-PRtest upstream/develop
   

3. 應用本地修改到新分支

   • 方法一：Cherry-pick
     我個人常用的是這個，首先找到localTest分支的提交哈希
     （使用git log localTest查看），然后：

      git cherry-pick <hash>
     

   • 方法二：合并修改內容
     將localTest的更改合并到clean-test：

     git merge localTest --squash  # 合并并壓縮為一個提交
     git commit -m "提交信息"
     

4. 強制推送到遠程test分支：

   git push origin clean-test:test --force
   

---

3. 回退add操作

首先看看哪些文件加進去了

git status

回退git add所有文件：

 git reset HEAD

回退部分文件：

git reset HEAD fileName

---

4. 交互式rebase

在使用 Git 進行交互式 rebase 時，您可能會用到 Vim 或類似的文本編輯器來修改提交歷史。以下是詳細的步驟和說明，幫助您理解如何在這種情況下使用 Vim 來進行操作。

4.1 切換模式

1. 正常模式切換到插入模式：如果需要編輯文本內容（如更改提交信息），首先確保自己處于 Vim 的 Normal Mode 。如果不是，請按 Esc 鍵退出其他模式。然后按下 i 鍵進入 Insert Mode 。此時，

2. 從可視模式或命令行模式切換到插入模式：
   如果當前處于可視模式（Visual Mode）或命令行模式（Command-line Mode），請先按 Esc 鍵返回到正常模式，然后再按 i、a 或 o 等鍵進入插入模式。具體來說，

   • i：在光標所在位置前開始插入；
   • a：在光標所在位置后開始插入；
   • o：在當前行下方新開一行并進入插入模式。

4.2 保存與退出

1. 保存更改：完成文本編輯后，按 Esc 鍵回到正常模式。要保存所做的更改而不退出 Vim 編輯器，請輸入 :w 并按回車鍵。

2. 退出編輯器：若要退出編輯器但不保存更改，請輸入 :q! 并按回車鍵（注意這會丟棄所有未保存的更改）。如果希望保存更改并退出，則輸入 :wq 或簡寫為 :x 并按回車鍵。

4.3 注意Rebase

• 在成功保存并退出 Vim 編輯器后，根據您的操作，Git 可能會提示您繼續 rebase 過程。這時，您需要運行 git rebase --continue 命令來完成整個 rebase 操作。此步驟可能需要重復多次，直到處理完所有的提交。

• 重要的是，在執行 rebase 操作之前，請確保理解 rebase 對提交歷史的影響，并確認它不會影響團隊成員的工作流程。特別是當涉及到已推送至遠程倉庫的提交時，應格外小心，因為 rebase 會改變提交歷史。

---

5. 合并多個commit

1. 合并最近 $n$ 個提交，$n<=20$：

   git rebase -i HEAD~n
   

2. 編輯提交列表：

   • 在打開的文本中，將你想要合并的所有提交前的pick改為squash或簡寫s，除了第一個提交保持pick不變。

     pick abcdefg 提交信息1
     squash hijklmn 提交信息2
     squash opqrstu 提交信息3
     

3. 保存并退出編輯器（Vim為例：按Esc, 輸入:wq, 按回車）。

4. 編輯合并后的提交信息：
   Git會再次打開編輯器讓你編輯新的合并提交的信息。編輯后，再次保存并退出。

5. 強制推送更新（如果已推送到遠程倉庫）：

   git push origin lcoal-branch:develop --force
   

    git push origin lcoal-branch:develop --f
   

強制推送會覆蓋遠程倉庫的歷史，所以如果其他人也在基于這些提交工作，可能會導致沖突。

---

問題一：Clone Github報錯The TLS connection was non-properly terminated.

最近在服務器上跑代碼，clone Github代碼報錯

GnuTLS recv error (-110): The TLS connection was non-properly terminated.

TLS握手

TLS（Transport Layer Security，傳輸層安全協議）握手是建立安全網絡連接的關鍵步驟。在Git通過HTTPS協議與遠程倉庫通信時，TLS握手的主要目的是：驗證服務器的身份，確保連接到的是合法的遠程倉庫；客戶端和服務器協商生成會話密鑰，用于后續的數據加密傳輸。

握手過程通常包括以下步驟：

1. 客戶端問候：客戶端向服務器發送支持的TLS版本、加密算法等信息。
2. 服務器問候：服務器選擇一種加密算法，并返回自己的證書用于身份驗證。
3. 密鑰交換：客戶端和服務器根據選定的加密算法協商生成會話密鑰。
4. 完成握手：雙方確認握手完成，開始使用會話密鑰進行加密通信。

報錯原因

當出現“gnutls_handshake() failed”錯誤時，說明在TLS握手過程中出現了問題，導致無法建立安全連接。以下是幾種常見原因：

1.代理設置問題

如果之前設置了代理，但當前網絡環境不需要代理，或者代理配置不正確，可能會干擾Git與遠程倉庫的直接通信，導致TLS握手失敗。Git在嘗試通過代理連接時，可能無法正確處理握手過程中的數據包，從而引發錯誤。

2. Git版本問題

舊版本的Git可能存在兼容性問題，導致與服務器的TLS握手出現異常。例如，某些版本的Git使用GnuTLS庫進行加密傳輸，在特殊情況下（如使用了代理服務器）可能出現握手失敗的問題。

3. SSL證書問題

本地SSL證書過期或不受信任，會導致服務器的SSL證書無法通過客戶端的驗證。這可能是由于證書頒發機構（CA）的證書未正確安裝，或者證書本身存在問題。

解決

清除代理設置

清除Git的代理配置，使Git能夠直接與遠程倉庫建立連接，避免代理設置導致的握手問題：

git config --global  --unset https.https://github.com.proxy
git config --global  --unset http.https://github.com.proxy

更新Git版本

更新Git到最新版本，以確保使用的是經過優化和修復的版本，避免因舊版本的兼容性問題導致握手失敗。在Linux系統上，可以通過包管理器（如apt-get）更新Git。

我清除代理之后就OK了。

問題二：Failed to connect to 127.0.0.1 port 7890 after 2030 ms: Couldn’t connect to server

git config --global --unset http.proxy

git config --global --unset https.proxy

---

Github相關

1. GIthub中的一些縮寫 LGTM !

最近經常看到一些迷之縮寫，感覺挺有意思的，但是有時候看到一些沒見過的縮寫還是有點懵逼，不過縮寫確實也是很方便去review，這里就記錄匯總一下；順便加了一些git的基操單詞（加粗的是我遇到比較多的）。

參考：
https://blog.csdn.net/liwenlong_only/article/details/104004928
https://blog.csdn.net/misayaaaaa/article/details/102684348
https://github.com/orgs/community/discussions/16925

縮寫	含義	說明
PR	Pull Request	拉取請求，用于向其他項目提交代碼
LGTM	Looks Good To Me	代碼已經過review，可以合并
SGTM	Sounds Good To Me	與LGTM意思相近，表示通過了review
WIP	Work In Progress	如果你有個改動很大的 PR，可以在寫了一部分的情況下先提交，然后在標題里寫上 WIP，以告訴項目維護者這個功能還未完成，方便提前 review 部分已經寫好的代碼
PTAL	Please Take A Look	你過來瞅瞅？
TBR	To Be Reviewed	提示維護者進行review
TL;DR	Too Long; Didn’t Read	太長懶得看，通常用于文檔的簡略描述前
TBD	To Be Done/Defined/Discussed/Decided/Determined	根據語境不同意義有所區別，但一般都是還沒搞定的意思
BTW	By The Way	順便說一下
FYI	For Your Information	供你參考
CC	Carbon Copy	抄送，用于提及某人以便其了解相關信息
API	Application Programming Interface	應用程序編程接口
CI/CD	Continuous Integration/Continuous Deployment	持續集成/持續部署
CR	Code Review	代碼審查
Doc	Document	文檔
Fork		創建一個項目的副本到自己的賬戶下
Repo	Repository	存儲代碼和其他資源的倉庫
HEAD		指向當前檢出分支的最新提交
Merge		將一個分支的更改合并到另一個分支中
Rebase		將一系列提交應用到另一個基礎分支上，通常用于整理提交歷史
Issue		用戶報告的問題或者待辦事項，可以是Bug報告、功能請求等
Label		用來標記Issues或PRs的分類標簽，幫助組織和跟蹤任務
RFC	Request For Comments	請求意見稿，一般是一個Markdown文件

2. Issue中的一些 Highlight

> [!NOTE]  
> Highlights information that users should take into account, even when skimming.> [!TIP]
> Optional information to help a user be more successful.> [!IMPORTANT]  
> Crucial information necessary for users to succeed.> [!WARNING]  
> Critical content demanding immediate user attention due to potential risks.> [!CAUTION]
> Negative potential consequences of an action.