feat(professional-stage): Add subsec3/1, 3/2, 3/3

Author: Dayuxiaoshui

Assignment.md

@@ -1,4 +1,4 @@
-- HCTT 文档翻译（自由选择一篇已收集的英文文档），按照 Wiki 中要求的流程完成 “翻译申请”，“翻译提交”等操作。
-- 选择 Git 游戏学习方式（https://learngitbranching.js.org），当然，这个游戏也是开源在Github上的项目，大家也可以选择向这个仓库进行开源贡献。
-- 在Github/Gitee上创新一个账号（如果没有的话），并使用工具提交自己的第一个commit，PR。
-- 在 pwn.hust.college平台 <https://pwn.cse.hust.edu.cn> 中完成 “Linux/Unix 基本命令使用” 道馆（**待创建**）。
+- HCTT 文档翻译（自由选择一篇已收集的英文文档），按照 Wiki 中要求的流程完成 “翻译申请”，“翻译提交” 等操作。
+- 选择 Git 游戏学习方式（https://learngitbranching.js.org），当然，这个游戏也是开源在 Github 上的项目，大家也可以选择向这个仓库进行开源贡献。
+- 在 Github/Gitee 上创新一个账号（如果没有的话），并使用工具提交自己的第一个 commit，PR。
+- 在 pwn.hust.college 平台 <https://pwn.cse.hust.edu.cn> 中完成 “Linux/Unix 基本命令使用” 道馆（**待创建**）。

docs/ch1/sec1/what-is-oss.md

@@ -1 +1,2 @@
 
+

docs/ch3/index.md

@@ -8,7 +8,7 @@
 
 代码托管平台是一种基于云服务的开发协作工具，主要用于存储、管理和协同开发代码项目。它通过集成版本控制系统（如 Git）、协作工具和自动化流程，为开发者提供全生命周期的代码管理支持，是现代软件开发和开源生态的核心基础设施。
 
-???+ node "类比理解--就像游戏云存档"
+???+ node “类比理解--就像游戏云存档”
 
     代码托管平台就像游戏的**云存档**功能。想象一下，你在玩游戏时，可以把游戏进度保存在本地（本地存档），但如果电脑坏了或者存档丢了，你的努力就白费了。而代码托管平台就像游戏的**云存档**，它把你的代码上传到云端服务器，即使你的电脑坏了，代码也不会丢失，随时可以从云端恢复。
 
@@ -48,51 +48,51 @@
 
 ### 其他常见术语
 
-???+ tip "小提示"
+???+ tip “小提示”
 
     这些内容在本课程后续会有更详细的讲解，目前只需要熟悉基本概念即可。其实，你可以把代码托管平台类比为微博、虎扑、贴吧、小红书或 Steam 这样的平台，只不过上面分享和讨论的内容是代码。其中很多概念都是相通的。
 
-#### 1. **复制仓库（Fork）**
+#### 1。**复制仓库（Fork）**
 
-- **是什么**：将别人的仓库复制到自己的账户下，就像你在微博上“转发”一条动态到自己的主页一样。
+- **是什么**：将别人的仓库复制到自己的账户下，就像你在微博上 “转发” 一条动态到自己的主页一样。
 - **为什么重要**：让你可以自由修改代码，就像你可以在转发的内容上加自己的评论或修改。同时，你还可以将改进贡献回原项目。
 - **使用场景**：参与开源项目、实验性修改，就像你看到一篇有趣的文章，想自己试试修改后再分享给别人。
 
 ---
 
-#### 2. **点赞/收藏（Star）**
+#### 2。**点赞/收藏（Star）**
 
 - **是什么**：对仓库点赞，表示支持或收藏，就像你在小红书或微博上给喜欢的帖子点个赞或收藏起来。
 - **为什么重要**：方便你快速找到喜欢的项目，同时也是对开发者的鼓励，就像你收藏了一篇好文章，以后可以随时翻出来看。
 - **使用场景**：收藏优质项目、支持开发者，比如你看到一个很棒的工具库，点个 Star 表示支持。
 
 ---
 
-#### 3. **关注仓库（Watch）**
+#### 3。**关注仓库（Watch）**
 
 - **是什么**：关注仓库，接收更新通知，就像你在虎扑或贴吧上关注一个话题，每次有新回复都会提醒你。
 - **为什么重要**：让你随时了解项目的动态，比如新功能发布或 Bug 修复，就像你关注的博主发了新内容，你会第一时间知道。
 - **使用场景**：跟踪感兴趣的项目、参与社区讨论，比如你关注了一个开源项目，想随时了解它的进展。
 
 ---
 
-#### 4. **问题跟踪（Issues）**
+#### 4。**问题跟踪（Issues）**
 
 - **是什么**：用于报告 Bug、提出新功能或讨论任务，就像你在 Steam 社区或贴吧里发帖提问或反馈问题。
 - **为什么重要**：是项目管理和协作的核心工具，帮助开发者沟通和解决问题，就像你在论坛上发帖后，其他人可以回复并提供解决方案。
 - **使用场景**：报告问题、提出改进建议、讨论技术细节，比如你发现了一个 Bug，可以在 Issues 里提出来。
 
 ---
 
-#### 5. **代码合并请求（Pull Request/Merge Request）**
+#### 5。**代码合并请求（Pull Request/Merge Request）**
 
 - **是什么**：请求将你的代码修改合并到原项目，就像你在贴吧或论坛上写了一篇长文，希望版主把它加进精华帖里。
 - **为什么重要**：是开源贡献的核心方式，让开发者可以协作改进代码，就像你写了一篇好文章，希望更多人看到并认可。
 - **使用场景**：提交代码改进、修复 Bug、添加新功能，比如你修复了一个问题，可以提交 Pull Request 让原作者合并你的修改。
 
 ---
 
-#### 6. **自动化工作流（CI/CD）**
+#### 6。**自动化工作流（CI/CD）**
 
 - **是什么**：自动化测试、构建和部署的工具，就像你在 Steam 上设置了自动更新游戏，每次有新版本都会自动下载安装。
 - **为什么重要**：提升开发效率，确保代码质量，就像你设置了自动回复，不用每次手动处理重复的事情。
@@ -122,7 +122,7 @@
 
 ## 总结
 
-!!! summary "学习目标"
+!!! summary “学习目标”
     - 了解常见的代码托管平台（如 GitHub、Gitee 等）及其基本功能。
     - 学会在浏览器中浏览和搜索仓库。
     - 掌握平台的基本概念，如 Fork、Star、Watch 等。

docs/ch3/sec1/subsec1/2-code-hosting-platforms.md

@@ -1,18 +1,18 @@
-# 实践：注册并熟悉代码托管平台 （易炜涵）
+# 实践：注册并熟悉代码托管平台
 
 > 学生注册代码托管平台账户并熟悉其功能。注册 GitHub、Gitee 等平台的账号。了解平台的主要功能界面，并做出一些常识。
 
 ## 具体步骤
 
-### 1. 注册账号
+### 1。注册账号
 
 1. **访问平台网站**：
    - GitHub: [https://github.com](https://github.com)
    - Gitee: [https://gitee.com](https://gitee.com)
 2. **创建账户**：
-   - 点击“Sign up”或“注册”按钮，按照提示填写信息完成注册。
+   - 点击 “Sign up” 或 “注册” 按钮，按照提示填写信息完成注册。
 
-??? tip "注册之后可以做的事"
+??? tip “注册之后可以做的事”
 
     完成 GitHub 注册后，可以做这些事：  
 
@@ -22,37 +22,37 @@
     4. **学生福利**：认证 GitHub Student Pack 免费解锁 Pro 功能；  
     意义：提升账户安全，建立专业形象，增加曝光机会，融入开发者社区，为求职或协作积累信用资产。
 
-### 2. 熟悉 github 平台功能
+### 2。熟悉 github 平台功能
 
 #### Dashboard 页面
 
 注册之后登录首先看到的应该是你的 Dashboard 界面，就像下图这样，不过你的可能比较空白（😁）
 
 ![Dashboard](../../../assets/Dashborad.png)
 
-图 1. Dashboard
-{: .caption }
+图 1。Dashboard
+{： 。caption}
 
-???+ node "Dashboard的介绍"
+???+ node “Dashboard 的介绍”
 
     GitHub Dashboard 是用户登录后的主工作界面，集中显示关注仓库的动态更新、推荐项目、待处理通知（Issues/PR）、近期代码提交记录，以及个人仓库列表和团队动态，支持快速跳转到代码审查、仓库管理等功能模块。
 
 #### repository 页面
 
-注册之后就可以做一些操作了，比如说收藏一个仓库，就是给这个仓库一颗⭐️，可以点击[这里](https://github.com/hust-open-atom-club/intro2oss)去送出你的第一颗⭐️
+注册之后就可以做一些操作了，比如说收藏一个仓库，就是给这个仓库一颗 ⭐️，可以点击[这里](https://github.com/hust-open-atom-club/intro2oss)去送出你的第一颗 ⭐️
 
 ![repository](../../../assets/repo.png)
 
-图 2. Repository
-{: .caption }
+图 2。Repository
+{： 。caption}
 
-???+ node "repository的介绍"
+???+ node “repository 的介绍”
 
     在 GitHub 仓库页面中，您会看到代码文件列表、README 文件、顶部导航栏（包括 Issues、Pull Requests、Actions、Projects、Wiki）、右侧功能栏（About、Releases、Packages、Contributors），以及 Issue 页面的左侧栏（Assignees、Labels、Projects、Milestone、Development）。此外，还有 Star、Fork、Watch、Code 等功能。建议从 README 文件开始，逐步熟悉 Issues 和 Pull Requests 等协作功能。
 
 ## 总结
 
-!!! summary "学习目标"
+!!! summary “学习目标”
     - 掌握代码托管平台（如 GitHub、Gitee）的注册与基本操作流程
     - 熟悉 GitHub 的核心功能界面，包括 Dashboard、Repository
     - 尝试使用 Star、Fork、Watch 等功能参与开源项目

docs/ch3/sec1/subsec1/3-practice-code-hosting-platforms.md

@@ -1,4 +1,4 @@
-# 创建并管理仓库 (Repository) （易炜涵）
+# 创建并管理仓库 (Repository)
 
 > 本实验旨在帮助学生掌握如何创建并管理云端代码仓库，并建立本地与云端仓库的同步连接。我们将通过两种不同的途径实现这一目标：一种是从 GitHub 网站开始操作，另一种是从本地计算机开始操作。
 
@@ -8,16 +8,16 @@
 
 在开发和协作过程中，**远程**和**本地**是两个非常重要的概念：
 
-- **本地**：指的是你当前使用的计算机环境，包括本地文件、开发工具和配置。例如，你在本地编写的代码、运行的测试、以及使用的 Git 仓库都属于“本地”的范畴。
+- **本地**：指的是你当前使用的计算机环境，包括本地文件、开发工具和配置。例如，你在本地编写的代码、运行的测试、以及使用的 Git 仓库都属于 “本地” 的范畴。
 - **远程**：指的是位于网络服务器上的资源和服务。例如，GitHub、Gitee 等代码托管平台上的仓库，或者云服务器上的应用程序和数据。
 
 理解这两个概念的区别和联系非常重要：
 - **本地**是你个人工作的起点，所有代码和修改最初都是在本地完成的。
 - **远程**是团队协作和共享的基础，通过将本地的更改推送到远程，你可以与他人共享代码、协同开发，并确保代码的安全备份。
 
-在 Git 中，**本地**通常指你的本地仓库，而**远程**指远程仓库（如 GitHub）。你需要通过 `git push` 将本地的更改同步到远程，或通过 `git pull` 将远程的更新拉取到本地。这种“本地-远程”协作模式是现代开发的核心实践之一。
+在 Git 中，**本地**通常指你的本地仓库，而**远程**指远程仓库（如 GitHub）。你需要通过 `git push` 将本地的更改同步到远程，或通过 `git pull` 将远程的更新拉取到本地。这种 “本地-远程” 协作模式是现代开发的核心实践之一。
 
-随着学习的深入，你会逐渐意识到“本地”和“远程”的更多应用场景，例如：
+随着学习的深入，你会逐渐意识到 “本地” 和 “远程” 的更多应用场景，例如：
 
 - 本地开发环境 vs 远程部署环境
 - 本地数据库 vs 远程数据库
@@ -29,7 +29,7 @@
 
 ## 从 GitHub 网站开始
 
-- **创建远程仓库**：登录 GitHub 并点击“New repository”按钮。填写仓库名称、描述并选择公开或私有。点击“Create repository”完成创建。
+- **创建远程仓库**：登录 GitHub 并点击 “New repository” 按钮。填写仓库名称、描述并选择公开或私有。点击 “Create repository” 完成创建。
 
 ![Create-repo](../../../assets/createrepo.png)
 
@@ -94,7 +94,7 @@ git init
 git add .
 ```
 
-**解释**： `git add .` 会将当前文件夹中的所有更改文件（包括新建的文件）添加到暂存区，准备提交。
+**解释**：`git add .` 会将当前文件夹中的所有更改文件（包括新建的文件）添加到暂存区，准备提交。
 
 - 使用 `git commit` 命令提交这些文件，`-m` 后面跟着的是提交说明：
 
@@ -106,7 +106,7 @@ git commit -m "Initial commit"
 
 ### 连接到远程仓库
 
-- 打开 GitHub 或其他 Git 托管服务，创建一个新的空仓库。无需勾选“Initialize this repository with a README”选项，因为我们已经在本地创建了一个 `README.md` 文件。
+- 打开 GitHub 或其他 Git 托管服务，创建一个新的空仓库。无需勾选 “Initialize this repository with a README” 选项，因为我们已经在本地创建了一个 `README.md` 文件。
 - 复制新仓库的远程 URL，通常会是 `https://github.com/yourusername/yourrepository.git`。
 - 在本地仓库中使用以下命令将本地仓库与远程仓库关联：
 

docs/ch3/sec1/subsec1/4-create-repo.md

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