【Git原理与使用二】Git 分支管理

1. 理解分支

在版本回退里，我们知道，每次提交Git都把它们串成一条时间线，这条时间线就可以理解为是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即 master 分支。

再来理解一下HEAD，HEAD 严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD 指向的就是当前分支。

每次提交，master分支都会向前移动一步，随着你不断提交，master分支的线也越来越长，而HEAD只要一直指向master分支即可指向当前分支，HEAD可以指向其他分支，被执行的分支就是当前工作的分支。

他们的流程大致如下：

2. 创建分支

2.1 git branch 查看/创建分支命令

该命令有2中作用：

1）列出所有分支，列出本地仓库中所有分支， *代表当前所在分支

2）创建新分支，但不会马上切换到该分支

3）删除分支 -d 选项，不能在当前分支删除当前分支

4）强行删除分支 -D 选项，不能在当前分支删除当前分支

git bransh  # 列出分支
git bransh [branch]  #创建分支
git bransh -d [branch]  #删除分支
git bransh -D [branch]  #强行删除分支

2.2 新建分支操作

直接使用 git branch dev 命令创建分支，再次用 git bransh 查看就可以看到新建分支以及当前所在分支，此时查看 .git 文件就可以看到refs/heads 中多出一个dev。

3. 切换分支

3.1 git checkout 切换命令

该命令除了之前的恢复文件到特定版本外，还可以进行切换分支，-b选项可以直接创建并切换到新创建的分支

git checkout [-b] [branch]

3.2 切换分支操作

直接使用 git checkout dev 命令就可以成功切换到dev分支了

4. 合并分支

4.1 git merge 合并分支命令

核心功能是将一个分支更改合并到当前分支，并将两个分支提交历史和修改内容更改合并到一起， --no-ff 选项表示禁用Fast forward模式，-m 可以在合并时带上自定义信息

git merge [branch]  # 合并分支
git merge --no-ff -m "message" [branch]  # 禁用Fast forward模式合并分支

4.2 合并类型

1）快速合并（Fast-Forward Merge）

如果目标分支是源分支的直接祖先（即源分支的提交历史完全包含目标分支的提交历史），Git 会执行快进合并。在这种情况下，Git 会直接将目标分支的指针移动到源分支的最新提交，不会生成新的合并提交。

2） 三路合并（Three-Way Merge）

如果目标分支和源分支的提交历史有分歧（即它们各自有独立的提交），Git 会执行三路合并。在这种情况下，Git 会找到两个分支的最近共同祖先（common ancestor），然后尝试将源分支的更改合并到目标分支，生成一个新的合并提交。

4.3 合并分支操作

在新建分支上写入文件并完成提交，然后切换到master分支就可以进行合并操作，之后输入 git merge dev 就可以完成分支的合并

因为是快速合并，所以dev和master都会指向最新一次提交

4.4 合并冲突

如果在不同分支上修改了同一个文件，那么就可能会存在冲突，此时git是没有办法知道哪些代码该去该留的，所以就会产生合并冲突

同时在dev1和master上修改test第三行，然后合并，就会发生冲突，此时要手动解决问题并再次添加提交，进入test可以看到3-7行就是冲突代码，需要对其进行取舍

修改完成后，要进行添加并提交，此时master会指向最新一次提交，而dev还会停留在之前修改的提交位置，此时可以打印验证，如图片所示，和预期一致

打印分支线可视图：

使用log的 --graph 选项可视图 ，–abbrev-commit选项是显示简化的提交哈希值

git log --graph --abbrev-commit

4.5 分支管理策略

在这种Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息。为了能够溯源，偏向于合并冲突所带来的能够看到分支信息的方式。

首先创建分支，添加提交一行，然后返回master后使用 git merge --no-ff -m “merge dev2” dev2 进行合并，这时用 git log --graph --abbrev-commit 就可以看到提交的信息了

5. 删除分支/临时分支

5.1 删除分支

合并完成后, dev 分支对于我们来说就没用了， 那么dev分支就可以被删除掉，注意不能在当前分支下删除当前分支。在当前master分支下使用 git bransh -d dev 就可以删除dev分支了

5.2 删除临时分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时，最好新建一个分支，我们可以将其称之为 dev3 分支。如果正在 dev3 分支上开发了一半，被产品经理突然叫停，此时这个分支还是必须就地销毁，留着无用了。这时使用传统的git branch -d 命令删除分支的方法是不行的，必须要用 git bransh -D [branch] 强行删除分支。

6. 分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：

7. bug分支

7.1 git stash 储存工作区信息命令

用于临时保存当前工作目录中的更改，同时将工作目录恢复到最近一次提交的状态。这使得开发者可以在不同任务之间快速切换，而无需提交未完成的更改。

注意：不能保存增加的文件，只能管理已经添加到.git仓库的工作区文件

git stash  # 保存当前工作目录中的所有未提交的更改
git stash list  # 列出所有保存的 stash
git stash apply  # 将最近一次保存的 stash 应用到当前工作目录，但不会删除该 stash
git stash pop  # 将最近一次保存的 stash 应用到当前工作目录，并从 stash 列表中删除该 stash
git stash drop stash@{<index>}  # 删除指定的 stash
git stash clear  # 删除所有保存的 stash

那存放的位置在哪呢？tree .git 就可以发现refs中多了个stash，这个就是保存的位置了

7.2 bug解决流程

当dev2进行部分代码开发，突然发现master有bug，这时要新建fix_bug分支解决bug，切换分支时会发现会对dev2修改内容进行提示，此时可以用 git stash 命令对所在分支工作区信息进行储藏

此时切换到master后新建fix_bug分支进行修改bug，修复后再将其合并到master中。

此时切回dev2继续进行开发，要将stash恢复回来，用 git stash list 查看列表，然后用 git stash pop 恢复之前存储的内容，之后继续开发，开发完成后就可以添加提交。

此时不能直接合并到master中，因为直接合并可能会导致冲突或者master代码出现新bug，所以此时应该先将master合并到dev2中，并解决可能出现的问题，解决完成后再合并到master中

最后删除2个分支完成开发