Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs add 4.1.3.1 and 4.1.3.2 and 4.1.3.3 #47

Closed
wants to merge 4 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/ch3/sec1/subsec1/3-practice-code-hosting-platforms.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# 实践:注册并熟悉代码托管平台 (易炜涵)
# 实践:注册并熟悉代码托管平台

> 学生注册代码托管平台账户并熟悉其功能。注册 GitHub、Gitee 等平台的账号。了解平台的主要功能界面,并做出一些常识。

Expand Down
2 changes: 1 addition & 1 deletion docs/ch3/sec1/subsec1/4-create-repo.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# 创建并管理仓库 (Repository) (易炜涵)
# 创建并管理仓库 (Repository)

> 本实验旨在帮助学生掌握如何创建并管理云端代码仓库,并建立本地与云端仓库的同步连接。我们将通过两种不同的途径实现这一目标:一种是从 GitHub 网站开始操作,另一种是从本地计算机开始操作。

Expand Down
88 changes: 88 additions & 0 deletions docs/ch3/sec1/subsec3/1-rebase-merge.md
Original file line number Diff line number Diff line change
@@ -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 其实很有趣!😉
61 changes: 61 additions & 0 deletions docs/ch3/sec1/subsec3/2-Control Process .md
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
## 4.1.3.2 Git 分布式版本控制工作原理

### 目的
理解 Git 的分布式版本控制工作原理,掌握如何在本地和远程分支之间协作和合并。

### 内容

#### 1。Git 的分布式特性
Git 是一个分布式版本控制系统,与集中式版本控制系统(如 SVN)不同,每个开发者的本地仓库都是完整的副本,包含了项目的完整历史记录。这种设计使得开发者即使在没有网络连接的情况下也可以进行大部分操作。Git 在处理版本控制时,不依赖于中央服务器,开发者可以随时推送、拉取代码,且不影响其他开发者的工作。

#### 2。分支管理与协作
在 Git 中,分支允许开发者并行工作。每个开发者可以在自己的本地仓库中创建一个分支,进行独立开发,直到完成后再合并到主分支。分支的协作方式使得开发者能够在不干扰他人的情况下进行功能开发、bug 修复或实验性修改。常见的分支类型包括:
- **主分支(master/main)**:项目的主干分支,通常保持稳定状态。
- **功能分支(feature)**:为实现某个特定功能而创建的分支,完成开发后会合并回主分支。
- **修复分支(hotfix)**:用于紧急修复生产环境中的问题。
- **开发分支(develop)**:团队协作中用于集成各种功能分支的分支。

#### 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。处理分支冲突
在合并分支时,可能会发生冲突,尤其是在多个开发者同时修改相同文件的情况下。Git 无法自动合并这些冲突,因此需要开发者手动干预。冲突的解决通常包括:
- 查看冲突文件,找到冲突标记的位置。
- 使用 git add 命令将解决后的文件标记为已解决。
- 使用 git commit 提交合并结果。
冲突的示例:
```bash
# 发生冲突后,编辑冲突文件
git add conflicted-file
git commit -m "Resolved merge conflict"
```
#### 5。推送与拉取操作
**推送(Push)**:将本地仓库的更改提交到远程仓库。推送操作要求本地分支与远程分支保持同步,且在推送之前需要先拉取(git pull)远程仓库的更新,以避免冲突。
```bash
git push origin feature-branch
```
**拉取(Pull)**:将远程仓库的更改拉取到本地仓库。拉取时 Git 会自动进行合并,或者如果使用 git pull --rebase,则会使用 rebase 方式进行合并。
```bash
git pull origin main
```
#### 6.Git 工作流建议
为了更高效地进行团队协作,Git 团队工作流通常包括以下几个步骤:
**1** 在主分支上拉取最新的代码。
**2** 创建功能分支并开发新特性。
**3** 完成开发后,先拉取主分支的最新更新。
**4** 合并主分支到功能分支,解决冲突后再推送。
**5** 提交 Pull Request 进行代码审查与合并。
**6** 删除已合并的分支。
这种工作流确保了团队成员之间的协作高效、代码合并清晰,并且避免了频繁的冲突。
### 总结
Git 的分布式版本控制提供了灵活、高效的协作机制。开发者通过分支和合并操作,可以在不同分支上并行工作,同时确保代码的整合性。理解 Git 的工作原理,尤其是如何在不同分支间协作与合并,是使用 Git 进行版本控制的重要技能。
113 changes: 113 additions & 0 deletions docs/ch3/sec1/subsec3/3-help-open.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,113 @@
## 4.1.3.2 Git 辅助本地项目开发

### 目的
掌握如何利用 Git 管理本地开发流程。

### 内容

#### 1。管理多个本地分支
在 Git 中,管理多个本地分支有助于开发与实验。每个功能、修复或实验都可以在独立的分支上进行,避免直接影响主分支的稳定性。通过合理的分支管理,可以确保代码的整洁和高效的开发流程。
- **创建本地分支**:
使用 `git branch` 命令创建新的分支。分支可以用来独立开发某个功能或实验性修改。创建分支后,使用 `git checkout` 命令切换到该分支进行开发。

示例:
```bash
git branch new-feature # 创建一个新的分支
git checkout new-feature # 切换到新分支
```
也可以通过 git checkout -b 命令同时创建并切换到新分支:
```bash
git checkout -b new-feature # 创建并切换到新分支
```
- **切换分支**
通过 git checkout 命令,开发者可以随时切换到不同的分支,继续开发其他功能或者修复问题。这使得多任务并行开发成为可能。
```bash
git checkout main # 切换到主分支
git checkout feature-branch # 切换到指定的功能分支
```
- **查看本地分支**:
使用 git branch 命令可以列出所有本地分支,当前所在的分支会以*标记。此命令帮助开发者了解自己在哪个分支上工作。
```bash
git branch
```
输出示例:
```bash
* feature-branch
main
develop
```
- **删除本地分支**:
完成开发或实验后,可以使用 git branch -d 命令删除已经不再需要的分支。如果分支还没有被合并,会有提示,要求确认删除。可以使用-D 强制删除。
```bash
git branch -d old-feature # 删除本地的旧功能分支
git branch -D feature-to-delete # 强制删除未合并的支
```
#### 2。合并本地分支
当在不同分支上进行开发后,通常需要将其合并到主分支或其他分支上。这可以通过 git merge 命令来实现。
- **合并分支**:
在目标分支上执行 git merge 命令,将另一个分支的修改合并到当前分支。这是开发过程中最常用的操作之一。
```bash
git checkout main # 切换到主分支
git merge new-feature # 将新特性分支合并到主分支
```
如果发生冲突,Git 会提示冲突的文件,开发者需要手动解决这些冲突。
- **解决合并冲突**:
如果 Git 在合并时发现冲突,会标记出冲突的部分。开发者可以通过编辑文件来手动解决冲突。解决冲突后,执行 git add 命令标记冲突已解决,然后执行 git commit 提交合并结果
```bash
# 解决冲突后,添加解决的文件
git add conflicted-file
# 提交合并结果
git commit -m "Resolved merge conflict"
```
#### 3。管理本地分支与远程分支的同步
如果你需要与远程仓库同步本地分支,可以使用 git fetch 和 git pull 命令。这些命令可以帮助你保持本地分支和远程分支的一致性。
- **从远程获取最新更改**:
使用 git fetch 命令可以从远程仓库获取最新的提交,而不自动合并。这可以帮助你查看远程仓库的变化,进行对比分析,而不会直接影响你的本地代码。
```bash
git fetch origin # 获取远程仓库的最新更改
```
- **拉取并合并远程更改**:
使用 git pull 命令可以从远程仓库拉取更新并自动合并到本地分支。若使用 git pull --rebase,则采用 rebase 策略代替合并操作,历史记录将更加线性。
```bash
git pull origin main # 拉取远程主分支的更改并合并
```
#### 4。实验性开发与回滚
Git 为开发者提供了很大的灵活性,特别是在进行实验性开发时。如果某个实验失败,开发者可以随时回滚到之前的稳定版本。你可以使用 git checkout、git reset 等命令来还原代码。
- **回滚到上一个提交**:
如果当前修改没有经过提交,想要恢复到上一次的提交状态,可以使用 git checkout 来恢复文件。
```bash
git checkout -- file.txt # 恢复文件到上一次提交的状态
```
如果想要撤销对某个文件的所有更改,可以使用:
```bash
git checkout -- . # 恢复所有文件到上一次提交的状态
```
- **重置分支到某个历史提交**:
如果需要将分支重置到某个历史提交,可以使用 git reset 命令。--hard 选项会清除所有未提交的更改,回到指定的历史版本。
```bash
git reset --hard HEAD~1 # 重置当前分支到上一个提交
```
如果希望保留文件的修改但回到某个历史提交,可以使用--soft 选项:
```bash
git reset --soft HEAD~1 # 保留修改,回到上一个提交
```
#### 5。使用 Stash 保存临时修改
在 Git 中,有时你可能需要暂时保存当前的工作进度,并切换到其他分支进行开发。这时可以使用 git stash 命令将未提交的更改保存到堆栈中。。
- **保存当前修改**:
使用 git stash 可以将当前的修改保存到堆栈中,然后恢复到干净的工作目录。
```bash
git stash # 保存当前修改
git stash list # 查看保存的stash
```
- **恢复保存的修改**:
使用 git stash pop 命令可以恢复最近保存的修改。该命令会将修改应用到当前分支,并从 stash 堆栈中删除。
```bash
git stash pop # 恢复最近保存的修改并从stash堆栈中删除
```
- **应用特定的 stash**:
如果有多个保存的 stash,可以指定应用某个特定的 stash。
```bash
git stash apply stash@{2} # 恢复第二个保存的stash
```
### 总结
Git 帮助开发者在本地进行多分支管理,提供了灵活的开发与实验机制。通过合理的分支管理、合并与回滚操作,可以有效提升开发效率,并保持代码的整洁与可维护性。同时,借助 stash 功能,开发者能够灵活处理临时任务,避免丢失未完成的工作。Git 的本地开发流程为团队提供了更高效的协作机制,使得开发者能够更加专注于功能开发、问题解决与实验创新。