版本控制器Git(3)

前言

我们在上篇讲到了分支，现在我们就着这个继续来讲解！

master分支稳定性：

dev分支作为开发主线：

个人分支与团队合作：

在这里插入图片描述
日常开发环境：

线上环境：

测试流程：

在这里插入图片描述
场景描述：假设你正在 dev2 分支上进行开发，但突然发现 master 分支存在一个需要立即修复的bug。根据最佳实践，不应该直接在 master 分支上修复问题，而是应该创建一个专门用于修复bug的临时分支。

暂存当前工作：当你在 dev2 分支的工作尚未完成且无法提交时，可以使用 git stash 命令将当前工作区的信息储藏起来。这允许你在不提交的情况下切换分支，并确保稍后可以恢复这些更改。

在这里插入图片描述
git stash：执行此命令后，Git会保存所有已经被追踪文件的修改，例如对 ReadMe 文件所做的编辑。

在这里插入图片描述

检查stash内容：git stash list：查看当前存储的所有stash记录，确认哪些改动被保存

创建bug分支：从 master 分支创建一个新的分支来专门解决发现的问题。比如修复 ReadMe 文件中少一个字母c导致的bug。

完成修复后，记得提交更改并合并回 master 分支
在这里插入图片描述

恢复工作区状态：修复完bug之后，你需要回到 dev2 分支继续未完成的工作。由于之前使用了 git stash，你现在可以通过 git stash pop 来恢复之前的工作区状态。这不仅恢复了你的改动，同时也清除了stash记录。

git stash pop：恢复最新的stash记录并将其从stash列表中删除。

分支间的差异：需要注意的是，即使你在 dev2 分支上恢复了之前的工作，它仍然基于修复bug之前的 master 状态，因此 dev2 分支不会包含修复后的代码。但这不影响你在 master 上所做的修复。

在这里插入图片描述
我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是有一定风险的。

是因为在合并分支时可能会有冲突，而代码冲突需要我们手动解决（在 master 上解决）。我们无法保证对于冲突问题可以正确地一次性解决掉，因为在实际的项目中，代码冲突不只一两行那么简单，有可能几十上百行，甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。

解决这个问题的一个好的建议就是：最好在自己的分支上合并下 master ，再让 master 去合并dev ，这样做的目的是有冲突可以在本地分支解决并进行测试，而不影响 master 。

在这里插入图片描述

在软件开发过程中，新功能的添加是一个持续不断的需求。为了确保主分支（通常是 main 或 master）的稳定性，不会因为实验性质的代码而受到影响，每开发一个新的功能时建议创建一个独立的分支，通常称之为 feature 分支。
这个分支用于隔离新功能的开发工作，直到该功能完成并经过测试后，再将其合并回主分支。之后，可以安全地删除 feature 分支，以保持仓库的整洁。

然而，有时候项目需求会发生变化。例如，如果你正在某个 feature 分支上开发新功能，但中途被要求停止开发——这可能是由于优先级的变化或其他原因——那么即使这部分工作尚未完成或合并，也需要删除这个 feature 分支。

在这种情况下，使用常规的 git branch -d 命令是不够的，因为它只允许删除已经被合并过的分支。对于未合并的分支，你需要使用强制删除命令：