二.Gitee分支管理
理解分⽀
分支（Branch）其实就是一个指针，指向某一次提交（commit）。
每次你提交一次（
git commit），就会生成一个新的快照（commit 对象）。分支名（比如
master）其实就是“最后一次提交”的引用，指向最新的提交。Gitee 默认创建的第一个分支叫
master
HEAD 是一个特殊的指针，表示你当前“在哪个分支上工作”。
通常情况下，HEAD 指向一个分支（比如 master），这个分支再指向一个具体的 commit。
HEAD指向的是master（当前分支）
master指向的是某个提交对象简单来说，分支就是指向最新commit对象的指针，分支可以有多个，而HEAD就是指向当前分支 并可以在这条分支上进行操作。
1.创建分支git branch dev
查看分支 git branch
当我们创建新的分⽀后，Git 新建了⼀个指针叫 dev， * 表⽰当前 HEAD 指向的分⽀是 master 分⽀。另外，可以通过⽬录结构发现，新的 dev 分⽀
、、
cat .git/refs/heads/* cat 读取 .git/refs/heads/ 目录下的所有本地分支文件的内容
里面内容是 每个分支当前指向的 提交（commit）哈希值，commit ID相同表示 两个分支都指向同一个 commit。
可以用git show 提交ID 查看具体的内容
2.切换分⽀git checkout
git checkout 分支
切换到dev分支后，创建新文件newfile 并add commmt添加提交 (一定要add+commit 未跟踪文件 不会随着分支切换而变化)
再切回到master主分支后，cat 查看却发现不存在newfile文件
可以看到dev和master指向的commit对象已经不同了!
因为我们是在dev分⽀上提交的，⽽master分⽀此刻的提交点并没有变，此时的状态如图
3.合并分⽀git merge
git merge dev
Fast-forward（快进式）合并：
如果 master 分支没有任何新的提交，并且 master 在 dev 的历史链上，那么 Git 不会创建新的合并节点，而是直接把 master 的指针“快进”到 dev 所在的位置。
4.删除分支git branch -d
并完成后, dev 分⽀对于我们来说就没⽤了， 那么dev分⽀就可以被删除掉，注意如果当前正处于某分⽀下，就不能删除当前分⽀
5.合并冲突
1.先在master分支中 把file文件覆盖写入111111 并add+commit进行追踪
2.创建dev1并切换 把file文件覆盖写入222222 并add commit
git checkout -b 创建并切换
此时master分支中的对file文件内容和dev1不一样，进行git merge合并会怎么样？
触发合并冲突 两分支修改的内容会同时出现，========上面是当前分支的，下面是合并分支的。
解决方式：用vim手动修改 自己判断选择，把不需要的删除 分隔线也要删
dd行删 :wq退出
git log --graph图形化分支结构
使用图形化结构显示，左边有红线的是master分支 右边是dev1分支。
master覆盖写file文件并add cmmit提交，让master dev1指向不同的commit对象出现分叉，后面进行合并
6.合并分支 --no-ff模式
Fast Forward 模式：
当你从 master 分支创建了一个 dev 分支，在 dev 上做了一些提交后，回到 master 执行：
如果 master 自创建 dev 后没有额外提交，那么 Git 会直接把 master 的指针“快进”到 dev 的位置。这就叫 Fast Forward 合并。
结果：不会生成新的 merge 提交。历史看起来像是线性发展的一部分。这就导致我们不知道最新提交是merge进来的 还是正常提交的
--no-ff 模式：
git merge --no-ff -m "合并注释" 分支名
强制 Git 生成一个合并提交，就是让Fast Forward模式有提交痕迹，知道是其它分支提交的。
7.bug 分⽀
当我们从dev2分支上进行开发时，发现master分支上有bug，怎么办？
有bug就再新开一个分支fix_bug 专门处理bug，处理完 在master分支上进行merge合并fix_bug分支。
这样master指向新的没有bug的新commit对象，但后面合并dev2时 会触发合并冲突怎么办？
虽然避免不了冲突，但我们不能让冲突发送在master分支上，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。
所以我们一般1.先在dev2分支上进行merge master合并主分支，并处理合并冲突 手动删除，确认无误后 再commit提交，
2.最后切换master 并合并dev2分支，这样master分支上就不会触发合并冲突。
下面我们实际操作一下：
1.先切到dev1 新增file文件内容表示 正在开发codeing...
2.这时候发现Bug 需要新建并切换到新分支上 处理Bug，但我们新开发的内容并不想提交怎么办？
先git add 先把改过的文件放入暂存区，再git stash push -m "注释" 临时保存当前所有改动
git stash 临时保存工作区已经add 但未commit的内容
先明确一下概念：只要是add过 就是已追踪的。
可以看到 不管之前有没有add过，如果有了新内容就必须add 放入暂存区staged中
状态 是 tracked(追踪) 吗？ 是 staged(暂存) 吗？ 能被 commit 吗？ 修改未 add 的已追踪文件 ✅ 是 ❌ 否 ❌ 否 修改后已 add 的文件 ✅ 是 ✅ 是 ✅ 是 新建未 add 的文件 ❌ 否 ❌ 否 ❌ 否 新建已 add 的文件 ✅ 是（add 后才被跟踪） ✅ 是 ✅ 是 
3.切换到master创建fix_bug分支，修改bug并提交，切回master 并merge --no-ff合并
此时状态
4.解决完bug 重新切换dev2 先git stash pop取出之前存入暂存区的内容，完成开发commit提交。最后合并master 手动修改冲突，得到无bug+新开发的内容，不要忘记commit提交。
git stash pop 恢复最近一次 stash 并从堆栈中删除
git stash list 查看所有 stash 条目
但这并没有触发冲突，为什么？
master修改的行 和 dev1新增行不在同一个改动块
触发合并冲突的条件：
1.当两边对同一“行”作了不同的修改，一定会发生冲突。
2.不一定在同一行 可能在修改行的附件也会发生
具体来说 修改同一个"改动块"合并会触发冲突
改动块（hunk）是一次
diff比较中检测到的、连续发生修改的区域。
它不是单纯的一行或一句话，而是 Git 自动识别的一段有变化的“连续行”上下文。
后面简单模拟一下冲突情况，直接在master修改同行，再回到dev1进行合并触发冲突。
5.最后返回master 合并dev1
8.删除临时分⽀
我们在dev2分支中开发到一半，不需要开发了需要删除dev2怎么办？
切到master分支 git branch -d dev2，但删除失败。
因为只有当 dev2 的所有提交已经被合并到当前分支时，Git 才会允许删除。
确定不需要 想直接丢弃未合并的提交可以用-D选项 强制删除