fix issues in ch3 (#86)

* fix issues in ch3

* fix issues in ch3

Author: xzss-ops

docs/ch3/index.md

@@ -4,9 +4,11 @@
     [@Dreadful_Me](https://github.com/Dreadful_Me)
 
 ## 🚀 开启 Git 与协作之旅  
+
 本章将带您系统掌握开源贡献全流程技能，从 Git 基础到高级协作，从个人项目管理到社区级贡献，通过渐进式学习路径成长为合格的开源贡献者。  
 
 ## markdown 基础
+
 !!! note 基本语法
     在这里，你将学习：
 
@@ -26,7 +28,6 @@
 
     8. 最后，利用**分割线**让不同的段落泾渭分明
 
-
 !!! warning 进阶语法
     除了基本的对文本的操作，markdown 文档能做的不止于此：
 
@@ -41,18 +42,19 @@
     - ......
 
 ## 💡 四阶段学习体系
+
 ### 1. [导学阶段](https://oss.hust.openatom.club/ch3/sec1/subsec1/1-git-introduction/)
 !!! tip "环境准备三步走"
     1. **平台初识**：GitHub/Gitee 功能探索
     2. **实战入门**：创建首个仓库
     3. **合规起点**：选择开源许可证
 
 !!! example "核心任务卡"
-    ```mermaid 
-    graph TB 
-    A[注册GitHub] --> B[创建个人仓库] 
-    A --> C[Fork俱乐部项目] 
-    B --> D[配置README] 
+    ```mermaid
+    graph TB
+    A[注册GitHub] --> B[创建个人仓库]
+    A --> C[Fork俱乐部项目]
+    B --> D[配置README]
     C --> E[提交首个Issue]
     ```
 
@@ -61,17 +63,17 @@
     | 场景 | 核心命令 | 应用要点 |
     |------|----------|----------|
     | 版本控制 | `git init/clone` | 建立版本库 |
-    | 变更管理 | `git add/commit` | 原子性提交 | 
-    | 问题排查 | `git diff/reset` | 撤销与比对 | 
+    | 变更管理 | `git add/commit` | 原子性提交 |
+    | 问题排查 | `git diff/reset` | 撤销与比对 |
 
 ### 3. [专业阶段](https://oss.hust.openatom.club/ch3/sec1/subsec3/1-rebase-merge/)
 !!! tip "高级工作流"
-    ```mermaid 
-    graph LR 
-    A[特性分支] --> B{合并策略} 
-    B -->|协作开发| C[Rebase] 
-    B -->|公共分支| D[Merge] 
-    C --> E[整洁历史] 
+    ```mermaid
+    graph LR
+    A[特性分支] --> B{合并策略}
+    B -->|协作开发| C[Rebase]
+    B -->|公共分支| D[Merge]
+    C --> E[整洁历史]
     D --> F[保留轨迹]
     ```
 
@@ -82,16 +84,17 @@
     - 通过邮件列表提交
 
 !!! success "团队协作评估"
-    ```mermaid 
+    ```mermaid
     pie
-    title 贡献评估维度 
+    title 贡献评估维度
     "代码质量" : 40
     "文档完善" : 25
     "Issue解决" : 20
     "社区互动" : 15
     ```
 
 ## 🔧 开发工具箱
+
 | 类别       | 推荐工具                  | 应用场景              |  
 |------------|-------------------------|-----------------------|  
 | **版本控制** | Git + GitLens           | 代码历史管理          |  
@@ -100,6 +103,7 @@
 | **调试分析** | GitHub Network Graph    | 项目关系可视化 |  
 
 ## 🌟 拓展技能树
+
 ```mermaid
 graph TD
   A[开源贡献技能] --> B[Linux训练营]
@@ -112,9 +116,10 @@ graph TD
   D --> I[Markdown精通]
   D --> J[文档工程]
 ```
+
 ## 🔧明星工具推荐
-!!! example "效率提升神器"
+
 - tmux：终端会话管理（多窗口操作）
 - better-commits：规范化提交助手
 - opencommit：AI 生成提交信息
-- pre-commit：自动化代码检查
+- pre-commit：自动化代码检查

docs/ch3/sec1/subsec3/1-rebase-merge.md

@@ -1,46 +1,46 @@
-## Git Rebase vs. Git Merge：选哪个？🤔
+# Git Rebase vs. Git Merge：选哪个？🤔
 
 **目的：**搞懂 Git 这两种合并分支的酷炫方式，以后合并代码不再纠结！
 
 **内容：**
 
 咱们先不讲那些复杂的理论，直接上例子，保证你一看就明白！
 
-### 场景模拟：团队合作开发新功能 🚀
+## 场景模拟：团队合作开发新功能 🚀
 
 假设你和小伙伴们正在一起开发一个超酷炫的新功能，每个人负责一部分：
 
-*   **你：**负责开发用户登录界面 (在 `feature/login` 分支)
-*   **小伙伴 A：**负责开发商品展示页面 (在 `feature/product` 分支)
-*   **主分支：**`main` 分支，是大家共同的基础
+* **你：**负责开发用户登录界面 (在 `feature/login` 分支)
+* **小伙伴 A：**负责开发商品展示页面 (在 `feature/product` 分支)
+* **主分支：**`main` 分支，是大家共同的基础
 
-#### Git Merge：简单粗暴，历史全记录 📖
+### Git Merge：简单粗暴，历史全记录 📖
 
-1.  **你完成了登录界面的开发，想要把代码合并到 `main` 分支：**
+1. **你完成了登录界面的开发，想要把代码合并到 `main` 分支：**
 
     ```bash
     git checkout main  # 切换到 main 分支
     git merge feature/login  # 把 feature/login 分支合并到 main 分支
     ```
 
-    *   **结果：**Git 会创建一个新的合并提交（merge commit），把你的 `feature/login` 分支和 `main` 分支的最新代码合并在一起。
+    * **结果：**Git 会创建一个新的合并提交（merge commit），把你的 `feature/login` 分支和 `main` 分支的最新代码合并在一起。
 
-    *   **特点：**简单！`main` 分支的历史记录会完整保留所有分支的开发过程，就像一本详细的日记。
+    * **特点：**简单！`main` 分支的历史记录会完整保留所有分支的开发过程，就像一本详细的日记。
 
-2.  **小伙伴 A 也完成了商品展示页面的开发，同样合并到 `main` 分支：**
+2. **小伙伴 A 也完成了商品展示页面的开发，同样合并到 `main` 分支：**
 
     ```bash
     git checkout main
     git merge feature/product
     ```
 
-    *   **结果：**又多了一个合并提交！
+    * **结果：**又多了一个合并提交！
 
-    *   **潜在问题：**如果很多人都在不同的分支上开发，`main` 分支的历史记录可能会变得很乱，像蜘蛛网一样 🕸️。
+    * **潜在问题：**如果很多人都在不同的分支上开发，`main` 分支的历史记录可能会变得很乱，像蜘蛛网一样 🕸️。
 
-#### Git Rebase：乾坤大挪移，历史更清晰 ✨
+### Git Rebase：乾坤大挪移，历史更清晰 ✨
 
-1.  **你完成了登录界面的开发，这次咱们用 `rebase`：**
+1. **你完成了登录界面的开发，这次咱们用 `rebase`：**
 
     ```bash
     git checkout feature/login  # 切换到 feature/login 分支
@@ -49,13 +49,13 @@
     git merge feature/login # 快速向前合并
     ```
 
-    *   **结果：** 
-        *   `rebase` 会把你的 `feature/login` 分支上的提交“移动”到 `main` 分支的最新提交之后。就像是把你的分支“嫁接”到了 `main` 分支上。
-        *   然后再次在 `main` 进行 `merge` 时，由于 `feature/login` 是直接从 `main` 分支“生长”出来的，所以可以直接快速合并（fast-forward），不会产生额外的合并提交。
+    * **结果：**
+        * `rebase` 会把你的 `feature/login` 分支上的提交“移动”到 `main` 分支的最新提交之后。就像是把你的分支“嫁接”到了 `main` 分支上。
+        * 然后再次在 `main` 进行 `merge` 时，由于 `feature/login` 是直接从 `main` 分支“生长”出来的，所以可以直接快速合并（fast-forward），不会产生额外的合并提交。
 
-    *   **特点：**干净！`main` 分支的历史记录会是一条直线，非常清晰。
+    * **特点：**干净！`main` 分支的历史记录会是一条直线，非常清晰。
 
-2.  **小伙伴 A 也用 `rebase` 合并：**
+2. **小伙伴 A 也用 `rebase` 合并：**
 
     ```bash
     git checkout feature/product
@@ -64,11 +64,11 @@
     git merge feature/product #快速向前合并
     ```
 
-    *   **结果：**同样，`main` 分支的历史记录依然保持一条直线。
+    * **结果：**同样，`main` 分支的历史记录依然保持一条直线。
 
-    *   **潜在问题：**`rebase` 会改写提交历史，如果你已经把 `feature/login` 分支推送到远程仓库，并且其他人在这个分支上工作，就不要用 `rebase` 了，否则会造成混乱。
+    * **潜在问题：**`rebase` 会改写提交历史，如果你已经把 `feature/login` 分支推送到远程仓库，并且其他人在这个分支上工作，就不要用 `rebase` 了，否则会造成混乱。
 
-### 总结：选哪个？
+## 总结：选哪个？
 
 | 特性         | Git Merge                                                                                             | Git Rebase                                                                                                                  |
 | :----------- | :---------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------ |
@@ -79,10 +79,10 @@
 | **比喻**   | **像一本详细的日记，记录了所有发生的事情**                                                                           | **像一棵树，主干清晰，分支从主干生长出来**                                                                                                |
 | **口诀**   | **`merge`虽乱心不乱，`rebase`虽直易出错**                                                                     | **`merge`虽乱心不乱，`rebase`虽直易出错**                                                                                  |
 
-### 趣味小练习 🎮
+## 趣味小练习 🎮
 
-1.  自己创建几个分支，分别用 `git merge` 和 `git rebase` 进行合并，看看有什么不同。
-2.  试着画出两种合并方式的提交历史图，加深理解。
-3.  思考一下，在你的团队项目中，哪种合并方式更适合？
+1. 自己创建几个分支，分别用 `git merge` 和 `git rebase` 进行合并，看看有什么不同。
+2. 试着画出两种合并方式的提交历史图，加深理解。
+3. 思考一下，在你的团队项目中，哪种合并方式更适合？
 
 希望这个文档能帮助你更好地理解 Git Rebase 和 Git Merge！记住，实践出真知，多动手试试，你会发现 Git 其实很有趣！😉

docs/ch3/sec1/subsec3/2-Control-Process.md

@@ -1,54 +1,74 @@
-## 4.1.3.2 Git 分布式版本控制工作原理
+# 4.1.3.2 Git 分布式版本控制工作原理
+
+## 目的
 
-### 目的
 理解 Git 的分布式版本控制工作原理，掌握如何在本地和远程分支之间协作和合并。
 
-### 内容
+## 内容
+
+### 1。Git 的分布式特性
 
-#### 1。Git 的分布式特性
 Git 是一个分布式版本控制系统，与集中式版本控制系统（如 SVN）不同，每个开发者的本地仓库都是完整的副本，包含了项目的完整历史记录。这种设计使得开发者即使在没有网络连接的情况下也可以进行大部分操作。Git 在处理版本控制时，不依赖于中央服务器，开发者可以随时推送、拉取代码，且不影响其他开发者的工作。
 
-#### 2。分支管理与协作
+### 2。分支管理与协作
+
 在 Git 中，分支允许开发者并行工作。每个开发者可以在自己的本地仓库中创建一个分支，进行独立开发，直到完成后再合并到主分支。分支的协作方式使得开发者能够在不干扰他人的情况下进行功能开发、bug 修复或实验性修改。常见的分支类型包括：
+
 - **主分支（master/main）**：项目的主干分支，通常保持稳定状态。
 - **功能分支（feature）**：为实现某个特定功能而创建的分支，完成开发后会合并回主分支。
 - **修复分支（hotfix）**：用于紧急修复生产环境中的问题。
 - **开发分支（develop）**：团队协作中用于集成各种功能分支的分支。
 
-#### 3。合并远程分支与本地分支
+### 3。合并远程分支与本地分支
+
 当开发者从远程仓库拉取更新（`git pull`）时，可能会遇到合并远程分支与本地分支的情况。Git 提供了几种方式来处理分支的合并：
+
 - **Git Merge**：通过 `git merge` 命令将不同分支的修改合并。此操作会生成一个新的合并提交，保留两个分支的历史记录。合并时，如果两个分支在同一部分文件有不同修改，Git 会提示冲突，需要手动解决。
+
   ```bash
   git checkout main
   git pull origin main
   git merge feature-branch
   ```
+
 - **Git Rebase**：通过 git rebase 命令将一个分支的提交“重放”到另一个分支的顶部。与 merge 不同，rebase 不会产生合并提交，而是将目标分支的修改按时间顺序添加到当前分支。这使得历史记录看起来更为线性，但也会改变提交历史，因此在共享分支上使用时需要谨慎。
+
   ```bash
   git checkout feature-branch
   git rebase main
   ```
-#### 4。处理分支冲突
+
+### 4。处理分支冲突
+
 在合并分支时，可能会发生冲突，尤其是在多个开发者同时修改相同文件的情况下。Git 无法自动合并这些冲突，因此需要开发者手动干预。冲突的解决通常包括：
+
 - 查看冲突文件，找到冲突标记的位置。
 - 使用 git add 命令将解决后的文件标记为已解决。
 - 使用 git commit 提交合并结果。
 冲突的示例：
+
 ```bash
 # 发生冲突后，编辑冲突文件
 git add conflicted-file
 git commit -m "Resolved merge conflict"
 ```
-#### 5。推送与拉取操作
+
+### 5。推送与拉取操作
+
 **推送（Push）**：将本地仓库的更改提交到远程仓库。推送操作要求本地分支与远程分支保持同步，且在推送之前需要先拉取（git pull）远程仓库的更新，以避免冲突。
+
 ```bash
 git push origin feature-branch
 ```
+
 **拉取（Pull）**：将远程仓库的更改拉取到本地仓库。拉取时 Git 会自动进行合并，或者如果使用 git pull --rebase，则会使用 rebase 方式进行合并。
+
 ```bash
 git pull origin main
 ```
-#### 6.Git 工作流建议
+
+### 6.Git 工作流建议
+
 为了更高效地进行团队协作，Git 团队工作流通常包括以下几个步骤：
 **1** 在主分支上拉取最新的代码。
 **2** 创建功能分支并开发新特性。
@@ -57,5 +77,7 @@ git pull origin main
 **5** 提交 Pull Request 进行代码审查与合并。
 **6** 删除已合并的分支。
 这种工作流确保了团队成员之间的协作高效、代码合并清晰，并且避免了频繁的冲突。
-### 总结
+
+## 总结
+
 Git 的分布式版本控制提供了灵活、高效的协作机制。开发者通过分支和合并操作，可以在不同分支上并行工作，同时确保代码的整合性。理解 Git 的工作原理，尤其是如何在不同分支间协作与合并，是使用 Git 进行版本控制的重要技能。