【Git】分⽀管理

创建分⽀(git branch dev)

git branch #查看当前本地所有分⽀
git checkout -b dev1 # 创捷一个新分⽀ dev1 ，并切换⾄⽬标分⽀
git branch dev #新建分⽀dev后，目录：.git/refs/如图所示

切换分⽀(git checkout dev)

切换分⽀后：HEAD指针就指向你切换的分支，而HEAD指向的分支就是当前操作的分支，git branch查看所有分支，前面有*的为主分支（当前分支）
git checkout dev# 切换到dev分⽀，即改变HEAD指针的指向

HEAD 已经指向了 dev，表⽰已经成功的切换到了 dev 上

在dev分⽀上提交，⽽master分⽀此刻的提交并没有变，所以他们分支查看到的东西不一样（若有一个分支改变过）

合并分⽀(git merge dev)

要将 dev 分⽀合并到 master 分⽀，当前分支操作合并分支的时候会奖操作的分支合并到当前分支，我们欲合并到master分支，所以要先切换到master分支

1. git checkout master # 切换到 master 上进⾏合并
2. git merge dev # 合并 dev 分⽀，git merge 命令⽤于合并指定分⽀到当前分⽀

两分支东西不一样，合并后，master 就能看到 dev 分⽀提交的内容了

删除分⽀（git branch -d dev）

当前正处于某分⽀下，就不能删除当前分⽀，欲删除dev分支，先切换到其他分支（master）

git branch -d dev // 删除分⽀dev

合并冲突

master，dev分⽀各⾃都分别有新的提交，种情况下，Git 只能试图把各⾃的修改合并起来，但这种合并就可能会有冲突，此时我们必须要⼿动调整冲突代码，并需要再次提交修正后的结果！

冲突就解决完成，此时的状态变成

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

git log也可以看到分⽀的合并情况，

git log --graph --pretty=oneline --abbrev-commit # 用于以简洁直观的方式展示提交历史和分支关系

1. –graph
   以 ASCII 字符绘制分支合并的拓扑图，直观展示分支之间的关系
2. –pretty=oneline
   指定提交信息的显示格式，将每个提交压缩为一行显示
3. –abbrev-commit
   简化 commit hash 的显示，只显示前 7 个字符（默认长度），而不是完整的 40 个字符哈希值

分⽀管理策略

合并分⽀时，如果可能，Git 会采⽤ Fast forward 模式：
Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提
交到底是 merge 进来的还是正常提交的

**
–no-ff ： 强制禁⽤ Fast forward 模式**，那么就会在 merge 时⽣成⼀个新的 commit ，这样，从分⽀历史上就可以看出分⽀信息

git merge --no-ff -m “merge with no-ff” dev2

分⽀策略

实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理：

1. master分⽀应该是⾮常稳定的，仅⽤来发布新版本，平时不能在上⾯⼲活；
2. dev分⽀上⼲活

团队合作的分⽀：

bug 分⽀（git stash：储藏当前的⼯作区信息）

假如我们现在正在 dev2 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有 bug，需要
解决。在Git中，每个 bug 都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除

dev2 的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？

1. git stash # 将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来。
   那么⽤ git status 查看⼯作区，就是工作区⼲净的

2. 基于master分⽀修复 bug，所以需要切回 master 分⽀，再新建临时分⽀来修复 bug
   修复完成后，切换到 master 分⽀，并完成合并，最后删除 fix_bug 分⽀

3. git checkout dev2 # 回到 dev2 分
   git stash list # 查看储藏的dev2
   git stash pop # 恢复的同时把 stash 储藏删了
   git stash apply # 仅恢复

修复 bug 的内容，并没有在 dev2 上显⽰。此时的状态图为：

预防合并冲突

Master 分⽀⽬前最新的提交，是要领先于新建 dev2 时基于的 master 分⽀的提交的，所以我们
在 dev2 中当然看不⻅修复 bug 的相关代码。
我们的最终⽬的是要让 master 合并 dev2 分⽀的，那么正常情况下我们切回 master 分⽀直接合
并即可，但这样其实是有⼀定⻛险的。是因为在合并分⽀时可能会有冲突，⽽代码冲突需要我们⼿动解决（在 master 上解决）。
我们⽆法保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单，有可能⼏⼗上百⾏，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。
此时的状态为：

解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并
dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。此时的状态
为：

删除临时分⽀(未commit)：git branch -D dev3

git中，对于还没有commit的临时分支用git branch -d dev3无法删除
git branch -D dev3 # 大D即可