【Git】：分支管理

目录

理解分支

创建分支

切换分支 

合并分支

删除分支

合并冲突

分支管理策略 

快进合并

正常合并

bug 分支 

 总结

---

理解分支

        在版本控制系统中，分支是一条独立的开发线路。它允许开发者从一个主要的代码基线（例如master分支）分离出来，进行独立的开发工作，如开发新功能、修复漏洞等，而不会影响主分支的稳定性。

 

创建分支

查看本地仓库中的所有分支，当前所在的分支会在列表中以 * 符号标记出来。

 git branch

 

创建一个新的分支

方法一：
git branch 新分支名方法二：
git checkout -b 新分支名
（创建完成分支后会自动切换过去）

方法一： 

 方法二：

 

 

切换分支 

git checkout 切换的分支名

 

合并分支

将一个或多个分支的修改合并到当前分支

git merge 要合并的分支

 我们来做一个简单的小实验

1. 在目录下创建一个文件test ，并且输入一行内容
2. 切换到 dev 分支下
3. 在 dev 分支下修改 test 文件，新增一行内容，并进行一次提交操作
4. 对比master分支 和 dev 分支 ，test 文件内容的区别

我们在目录下创建一个文件test ，并且输入一行内容

 我们切换到 dev 分支下

在 dev 分支下修改 test ⽂件，新增一行内容，并进行一次提交操作

 对比master分支 和 dev 分支 ，test 文件内容的区别

 总结：在 master 分支上，内容没有添加，在 dev 分支上，内容添加了。为什么会出现这个现象呢？我们来看看 dev 分支和 master 分支指向，发现两者指向的提交是不⼀样的

看到这里就能明白了，因为我们是在dev 分支上提交的，而master 分支此刻的提交点并没有变，此时的状态如图如下：

为了在 master 主分支能看到新的提交，就需要将 dev 分支合并到 master 分支

删除分支

删除本地分支（已经合并过的分支）

git branch -d 要删除的分支名

强制删除本地分支（未合并的分支）

git branch -D 要删除的分支名

 有些时候我们开发一个分支开发到一半，还没有合并，如果这个时候我们不想要了，我们想要删除分支就得强制删除本地分支

合并冲突

我们来做一个简单的小实验

1. 创建⼀个新的分支 dev ，并切换至dev 分支
2. 在 dev 分支 下修改 test   ⽂件，更改文件内容，并提交
3. 切换到  master 分支 ，观察 test  文件内容，对 test 文件再进行一次修改，并提交
4. master 分支 和 dev分支 进行合并

创建⼀个新的分支 dev ，并切换至dev 分支

 在 dev 分支下修改 test ⽂件，更改文件内容，并提交

切换到 master 分支，观察 test 文件内容，对 test 文件再进行一次修改，并提交

master 分支 和 dev分支 进行合并，这种情况下，Git 只能试图把各自的修改合并起来，但这种合并就可能会有冲突

 

 此时我们必须要手动调整冲突代码，并需要再次提交修正后的结果！！

到这里冲突就解决完成，此时的状态变成了

 

分支管理策略 

查看提交历史的命令，类图形化查看提交历史

git log --graph --pretty=oneline --abbrev-commit

 我们有两种分支合并的方法，我们应该如何去选择呢？

• 快进合并（Fast - forward Merge）
• 正常合并（Three - way Merge）

快进合并

适用场景和条件：这种合并适用于源分支是目标分支的直接后继，并且源分支上的所有提交都是在目标分支最新提交的基础上线性进行的情况。例如，从master分支创建new - feature分支后，master分支没有新的修改，而new - feature分支进行了一系列的提交。

 

正常合并

适用场景和条件：当目标分支和源分支有独立的提交历史，即从它们的共同祖先之后有各自的修改时，需要进行正常合并。例如，master分支和feature - branch都有从共同祖先之后的新提交。

 

我们可以强制禁用 快进合并 模式，那么就会在 merge 时⽣成⼀个新的 commit ，这样，从分支历史上就可以看出分支信息。

git merge --no-ff -m "提交文件的描述" 合并的分支名

不使用 快进合并模式，合并后就像这样 ：

bug 分支 

1. 假如我们现在正在 dev2 分支上进行开发，开发到⼀半，突然发现 master 分支之上面有 bug，需要解决
2. 每个 bug 都可以通过⼀个新的临时分支来修复，修复后，合并分支，然后将临时分支删除
3. 可现在 dev2 的代码在工作区中开发了⼀半，还无法提交，怎么办？

暂时保存当前工作目录的修改，这些修改可以是未提交的文件修改、新添加的文件或者暂存区（stage area）中的修改。它允许你在不提交当前工作的情况下切换分支或者处理其他紧急任务，之后再回来恢复这些修改继续工作。

git stash

查看所有已保存的stash（暂存）记录的列表。当你使用git stash命令保存工作目录和暂存区的修改时，这些修改会被存储在一个栈结构中，git stash list命令就是用来查看这个栈中所有记录的详细信息的。

git stash list

用于恢复并删除git stash栈顶（最新保存）的修改记录的命令。它结合了git stash apply（应用暂存的修改）和git stash drop（删除暂存的修改）的功能。 

git stash pop      // apply + dropgit stash apply    // 恢复工作区的内容
git stash drop     // 删除暂存的修改

但我们注意到了，修复 bug 的内容，并没有在 dev2 上显示。此时的状态图为： 

1. master 分支目前最新的提交，是要领先于新建 dev2 时基于的 master 分支的提交的，所以我们在 dev2 中当然看不见修复 bug 的相关代码
2. 我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是有⼀定风险的
3. 是因为在合并分支时可能会有冲突，而代码冲突需要我们手动解决（在 master 上解决）。
4. 我们无法保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项目中，代码冲突不只⼀两行那么简单， 有可能几十上百行，甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。

 

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

此时的状态为：

 总结

1. 假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50% 的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再⼀次提交，又存在丢失每天进度的巨大风险。
2. 现在有了分支，就不用怕了。你创建了⼀个属于你自己的分支，别人看不到，还继续在原来的分支上正常⼯作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
3. 并且 Git 无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。