-
Notifications
You must be signed in to change notification settings - Fork 11
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs add 4.1.3.1 and 4.1.3.2 and 4.1.3.3
- Loading branch information
1 parent
c65b3ef
commit ecb91e6
Showing
2 changed files
with
174 additions
and
172 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,89 +1,61 @@ | ||
## Git 分布式版本控制:代码世界的“多人运动”! 🏃♀️🏃♂️ | ||
|
||
**目的:** 啥是 Git 的“分布式”?别怕,咱们一起玩着就明白了! | ||
|
||
**内容:** | ||
|
||
想象一下,你们团队要一起盖一座乐高城堡 🏰,每个人负责不同的部分: | ||
|
||
* **你:** 负责城堡的大门 (在 `feature/gate` 分支) | ||
* **小伙伴A:** 负责城堡的塔楼 (在 `feature/tower` 分支) | ||
* **小伙伴B:** 负责城堡的围墙 (在 `feature/wall` 分支) | ||
* **GitHub/GitLab/Gitee:** 就像一个乐高积木的仓库,大家可以把自己的乐高零件(代码)放到这里,也可以从这里拿别人分享的零件。 | ||
|
||
#### Git 分布式:每个人都有自己的乐高盒子! 📦 | ||
|
||
* **集中式版本控制 (比如 SVN):** 只有一个中央乐高盒子,每次你想拼乐高,都得从中央盒子拿,拼完了再放回去。如果盒子管理员不在,或者盒子丢了,就完蛋了! | ||
* **Git 分布式版本控制:** 每个人都有一个完整的乐高盒子!你可以在自己的盒子里随便拼,拼好了再和别人的盒子同步。即使中央盒子丢了,也没关系,每个人的盒子里都有完整的备份! | ||
|
||
#### 玩转 Git 分布式,就像拼乐高! | ||
|
||
1. **克隆 (clone):** 从 GitHub/GitLab/Gitee 上把整个乐高城堡的设计图纸复制一份到你的电脑上。 | ||
|
||
```bash | ||
git clone <远程仓库地址> | ||
``` | ||
|
||
2. **分支 (branch):** 每个人都从主设计图纸(`main` 分支)上复制一份,开始搭建自己的部分。 | ||
|
||
```bash | ||
git checkout -b feature/gate # 你创建并切换到 feature/gate 分支,开始搭建城堡大门 | ||
``` | ||
|
||
3. **提交 (commit):** 你拼好了一个乐高积木,觉得很满意,就把它“咔哒”一声固定在你的城堡大门上。 | ||
|
||
```bash | ||
# 拼好了一个乐高积木... | ||
git add . | ||
git commit -m "我拼好了一个超酷的城门吊桥!" | ||
``` | ||
|
||
4. **推送 (push):** 你觉得你的城门吊桥太酷了,想分享给小伙伴们看看,就把你的 `feature/gate` 分支推送到 GitHub/GitLab/Gitee。 | ||
|
||
```bash | ||
git push -u origin feature/gate | ||
``` | ||
|
||
5. **拉取 (pull):** 小伙伴A 搭建好了城堡的塔楼,你想看看他的塔楼长啥样,就把他的 `feature/tower` 分支拉到你的本地。 | ||
|
||
```bash | ||
git pull origin feature/tower | ||
``` | ||
|
||
6. **合并 (merge):** 你觉得小伙伴A 的塔楼很棒,想把它拼到你的城堡上,就把 `feature/tower` 分支合并到你的 `feature/gate` 分支。 | ||
|
||
```bash | ||
git merge feature/tower | ||
``` | ||
|
||
7. **冲突解决 (resolve conflicts):** 糟糕!你和小伙伴A 都想在同一个地方放一个窗户,Git 不知道该听谁的了,就会提示冲突。你需要手动打开“冲突”的乐高积木,决定最终的设计,然后再次“咔哒”一声固定。 | ||
|
||
```bash | ||
# 手动打开冲突的乐高积木,决定最终的设计... | ||
git add . | ||
git commit -m "我和小伙伴A一起决定了窗户的最终位置!" | ||
``` | ||
|
||
8. **合并到主分支 (merge to main):** 你的城堡大门终于完工了!你把它合并到主设计图纸(`main` 分支)上,并推送到 GitHub/GitLab/Gitee。 | ||
|
||
```bash | ||
git checkout main | ||
git merge feature/gate | ||
git push origin main | ||
``` | ||
|
||
### 总结:Git 分布式,就是这么简单! | ||
|
||
* 每个人都有自己的代码仓库,可以离线工作。 | ||
* 通过推送和拉取来同步代码。 | ||
* 用分支来隔离不同的开发任务。 | ||
* 合并分支来整合代码。 | ||
* 解决冲突来确保代码的一致性。 | ||
|
||
### 趣味小挑战 🏆 | ||
|
||
1. 和小伙伴们一起,用 Git 协作完成一个小项目(比如写一篇博客、画一幅画、写一首歌)。 | ||
2. 故意制造一些冲突,看看 Git 是如何提示的,然后一起解决冲突。 | ||
3. 把你的 Git 仓库分享到 GitHub/GitLab/Gitee 上,让更多人看到你的作品! | ||
|
||
掌握了 Git 分布式版本控制,你就可以和全世界的开发者一起玩转代码啦!🌍🎉 | ||
## 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进行版本控制的重要技能。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,83 +1,113 @@ | ||
## Git:本地开发的超级助手!🦸 | ||
|
||
**目的:** 学会用 Git 来管理你的本地项目,就像玩游戏一样轻松切换不同的“存档”! | ||
|
||
**内容:** | ||
|
||
想象一下,你正在开发一个游戏角色 👾,你想尝试不同的技能组合: | ||
|
||
* **方案A:** 火焰 🔥 + 冰冻 ❄️ | ||
* **方案B:** 闪电 ⚡ + 隐身 👻 | ||
* **方案C:** 剧毒 🧪 + 治疗 🌱 | ||
|
||
如果不用 Git,你可能需要创建三个不同的文件夹,分别保存不同的代码。但是有了 Git,一切都变得简单了! | ||
|
||
#### Git 分支:就像游戏的“存档点”! 💾 | ||
|
||
Git 的分支就像是游戏的“存档点”,你可以在不同的存档点之间自由切换,尝试不同的方案,而不用担心搞乱你的代码。 | ||
|
||
#### 玩转 Git 本地分支,只需几步! | ||
|
||
1. **创建分支 (branch):** 为你的每个技能组合创建一个分支。 | ||
|
||
```bash | ||
git branch feature/fire-ice # 创建火焰+冰冻分支 | ||
git branch feature/thunder-stealth # 创建闪电+隐身分支 | ||
git branch feature/poison-heal # 创建剧毒+治疗分支 | ||
``` | ||
|
||
2. **查看分支 (branch):** 看看你都有哪些分支。 | ||
|
||
```bash | ||
git branch | ||
``` | ||
你会看到类似这样的输出: | ||
* feature/fire-ice | ||
feature/poison-heal | ||
feature/thunder-stealth | ||
* main | ||
|
||
`*` 表示你当前所在的分支。 | ||
|
||
3. **切换分支 (checkout):** 在不同的技能组合之间切换。 | ||
|
||
```bash | ||
git checkout feature/thunder-stealth # 切换到闪电+隐身分支 | ||
``` | ||
|
||
现在,你可以在 `feature/thunder-stealth` 分支上修改代码,实现闪电和隐身技能。这些修改不会影响其他分支的代码。 | ||
|
||
4. **提交 (commit):** 在当前分支上修改代码,并提交。 | ||
|
||
```bash | ||
# 修改了一些代码... | ||
git add . | ||
git commit -m "实现了闪电技能的初步效果!" | ||
``` | ||
|
||
5. **合并分支 (merge):** 如果你觉得某个技能组合很棒,想把它合并到主分支(`main` 分支),可以这样做: | ||
|
||
```bash | ||
git checkout main # 切换到 main 分支 | ||
git merge feature/thunder-stealth # 把 feature/thunder-stealth 分支合并到 main 分支 | ||
``` | ||
|
||
6. **删除分支 (branch -d):** 如果你觉得某个技能组合不怎么样,或者已经合并到 `main` 分支了,可以删除它: | ||
|
||
```bash | ||
git branch -d feature/fire-ice # 删除 feature/fire-ice 分支 | ||
``` | ||
|
||
### 总结:Git 本地分支,就是这么好用! | ||
|
||
* 你可以创建多个分支,分别开发不同的功能或尝试不同的方案。 | ||
* 你可以随时切换分支,就像切换游戏的存档点一样。 | ||
* 你可以把满意的分支合并到主分支,也可以删除不需要的分支。 | ||
|
||
### 趣味小挑战 🕹️ | ||
|
||
1. 在你的一个项目中(比如你的作业、你的博客、你的小游戏),创建几个分支,分别尝试不同的修改。 | ||
2. 试着在不同的分支上修改同一个文件的同一部分,然后切换分支,看看会发生什么。 | ||
3. 画出你的项目的分支图,看看它像什么(一棵树?一张网?)。 | ||
|
||
有了 Git,你的本地开发就像开了挂一样!你可以大胆尝试各种想法,再也不用担心把代码搞乱了!🚀 | ||
## 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的本地开发流程为团队提供了更高效的协作机制,使得开发者能够更加专注于功能开发、问题解决与实验创新。 |