目標：整理Git工具的應用場景和使用經驗
一、開發環境
Git是代碼版本控制工具；Github是代碼托管平臺。
工具組合：VSCode + Git
需要安裝的軟件：vscode、Git
其中vscode需要安裝的插件：GitLens、Git History
二、應用場景
工作場景：嵌入式開發，本地使用
三、使用總結
基礎操作，參考廖雪峰的Git教程
Git教程 - 廖雪峰的官方網站
Git 基本工作流程
3.1 版本管理
3.1.1 更改提交
git commit
使用 git commit 將當前工作目錄的更改保存到本地代碼庫。
每次提交（commit）都會創建一個新的提交對象，
避免將無關或不相關的修改混合在一起提交。
3.1.2 版本回退
兩種方式：reset、revert
git?reset
通過改變HEAD和分支指針指向的方式，進行版本回退，
該操作之后的提交記錄不會被保留，并且不會創建新的提交；
git revert
通過創建一個新提交的方式來撤銷某次操作，該操作之前和之后的提交記錄都會被保留，
并且會將該撤銷操作作為最新的提交；
在個人開發上，建議使用reset；但在團隊開發中建議使用revert，
特別是公共的分支（比如master)，這樣能夠完整保留提交歷史，方便回溯。
3.2 分支管理
一個分支代表一條獨立的開發線，使用分支可以從開發主線上分離開來，
不影響主線的同時繼續工作。
注：未被放入代碼庫的文件會在分支切換時被拋棄，造成嚴重后果。
3.2.1 分支切換
git switch
使用git switch <branch_name> 來切換到指定的分支。
3.2.2 分支合并
兩種方式：merge、rebase
相同點：都是從一個分支合并到當前分支。
注意：無論選擇哪種方式，都應該謹慎處理可能產生的沖突，
并確保在操作前備份代碼或創建臨時分支以防意外。
git merge
自動創建一個新的commit，如果遇到沖突，僅需要修改后重新commit。
方式：git merge會將目標分支的提交歷史合并到當前分支，形成一個新的合并提交。
這種方式被稱為"合并提交"或"三方合并"，因為它保留了每個分支的獨立提交歷史。
結果：合并后的提交歷史會包含源分支和目標分支的所有共同提交以及合并提交。
場景：適用于合并公共分支、團隊開發時的代碼集成，或者希望保留分支獨立性的情況。
合并穩定的公共分支，如主分支或發布分支。多人協作開發時，將各自的特性分支合并到開發分支。
git?rebase
找公共的節點，直接合并之前commit歷史，得到簡潔的分支發展歷史，去掉了merge commit。
方式：git rebase會將當前分支的提交"移動"到目標分支的最新提交之后，
然后將目標分支的提交歷史應用到當前分支。這種方式被稱為"變基"，因為它改變了提交的基點。
結果：合并后的提交歷史是線性的，沒有合并提交，看起來更加整潔。
但是原始分支的提交歷史會被修改，可能會導致沖突。
場景：適用于想要保持線性提交歷史、清晰的提交記錄，并希望將自己的提交"放到"目標分支上進行整合的情況。
最好不要在公共分支上使用rebase，如果前后基本上不會有別人改動你的分支，那么推薦rebase。
總結來說，在單人本地多分支開發中，使用變基操作來修復bug并更新所有分支是可行的，
可以確保所有分支都包含了最新的修復，并保持提交歷史的線性和清晰。
但是仍然建議在執行變基操作之前，仔細考慮其可能帶來的影響，并確保備份了代碼。
3.3 標簽管理
標簽也是版本庫的一個快照。
發布版本時，通常在版本庫中打個標簽（tag），則唯一確定打標簽時刻的版本。
切換到某個標簽，則相當于把打標簽時刻的歷史版本取出。
注意：標簽總是和某commit掛鉤。若該commit既出現在master分支，
又出現在dev分支，則在這兩個分支上都可看到此標簽。
3.3.1 標簽切換
使用git checkout <tagname>可將git倉庫的HEAD指針指向標簽所在的提交，
如：git checkout v1.0
3.4 開發管理
涉及到多人協作，如果沒有清晰的流程和規劃，每個人都提交一堆雜亂無章的 commit，
項目很快就會變得難以協調和維護。Git 版本管理同樣需要一個清晰的流程和規范。
3.4.1 Git flow
Git flow的優點是清晰可控，缺點是相對復雜，需要同時維護兩個長期分支。
該模式是基于"版本發布"的，目標是一段時間以后產出一個新版本。
長期分支：主分支master、開發分支develop。
前者用于存放對外發布的版本，任何時候在這個分支拿到的，都是穩定的分布版；
后者用于日常開發，存放最新的開發版。
短期分支：功能分支（feature branch）、補丁分支（hotfix branch）、發布分支（release branch）。
3.4.2 Github flow
Github flow 是Git flow的簡化版，專門配合"持續發布"。
3.4.3 Gitlab flow
Gitlab flow 是 Git flow 與 Github flow 的綜合。
它吸取兩者的優點，既有適應不同開發環境的彈性，又有單一主分支的簡單和便利。
四、經驗總結
4.1 文件未修改，但出現在工作區
修改文件權限可修復該異常。
項目修改：git config core.filemode false
全局修改：git config --global core.filemode false如果在Linux和windows之間傳遞代碼，可能出現該異常。
修改換行符轉換設置，可修復該異常。
git config --global core.autocrlf false
git config --global core.filemode false
git config --global core.safecrlf true4.2 如何使.gitignore中新增設置對之前的文件生效
$ git rm -r --cached . #清除緩存 -r 表示遞歸刪除（如果有文件夾的話） . 表示所有文件
$ git add . #重新trace file
$ git commit -m "update .gitignore" #提交和注釋$ git status --ignored #查看狀態，包括忽略的文件4.3 導出歷史提交記錄
git log --pretty=format:"%ai , %an: %s" >> ./commit.log
在項目根目錄下執行命令,導出 git 提交記錄到桌面git log --pretty=format:"%ai , %an: %s" --since="100 day ago" >> ./commit.log
如果想導出某些提交者的提交記錄,可以用grep過濾,比如我想導出zen這個人在項目中的提交記錄:git log --pretty=format:"%ai , %an: %s" --since="126 day ago" | grep "zen" >> ./commit.log
當然也可以導出成 Excel 文件git log --date=iso --pretty=format:'"%h","%an","%ad","%s"' >> ./commit.log%ai: 表示提交的時間，格式為 ISO 8601 標準的時間（例如 2024-04-16 14:30:00）。
%an: 表示提交者的名字。
%s: 表示提交時填寫的概要或簡短描述。| 選項 | 說明 |
|---|---|
|
| 按補丁格式顯示每個提交引入的差異。 |
|
| 顯示每次提交的文件修改統計信息。 |
|
| 只顯示 --stat 中最后的行數修改添加移除統計。 |
|
| 僅在提交信息后顯示已修改的文件清單。 |
|
| 顯示新增、修改、刪除的文件清單。 |
|
| 僅顯示 SHA-1 校驗和所有 40 個字符中的前幾個字符。 |
|
| 使用較短的相對時間而不是完整格式顯示日期（比如“2 weeks ago”）。 |
|
| 在日志旁以 ASCII 圖形顯示分支與合并歷史。 |
|
| 使用其他格式顯示歷史提交信息。可用的選項包括 oneline、short、full、fuller 和 format（用來定義自己的格式）。 |
|
|
|
| 選項 | 說明 |
|---|---|
|
| 提交的完整哈希值 |
|
| 提交的簡寫哈希值 |
|
| 樹的完整哈希值 |
|
| 樹的簡寫哈希值 |
|
| 父提交的完整哈希值 |
|
| 父提交的簡寫哈希值 |
|
| 作者名字 |
|
| 作者的電子郵件地址 |
|
| 作者修訂日期（可以用 --date=選項 來定制格式） |
|
| 作者修訂日期，按多久以前的方式顯示 |
|
| 提交者的名字 |
|
| 提交者的電子郵件地址 |
|
| 提交日期 |
|
| 提交日期（距今多長時間） |
|
| 提交說明 |
| %ai | 表示提交的時間，格式為 ISO 8601 標準的時間 |
資料整理自網絡
Git 歷史提交日志導出到文件中 | 張益銘的博客 (zhangyiming748.github.io)
Git - 查看提交歷史 (git-scm.com)
git日志導出命令 - xh_Blog - 博客園 (cnblogs.com)
Git 教程|極客教程 (geek-docs.com)
Git 歷史提交日志導出到文件中_eclipse導出git提交記錄-CSDN博客
數據)
