Git企业开发--分支管理

很高兴和大家见面，给生活加点impetus！！开启今天的编程之路

作者：٩( ‘ω’ )و260
我的专栏：Linux，C++进阶，C++初阶，数据结构初阶，题海探骊，c语言
欢迎点赞，关注！！

Git企业开发

理解分支

假设情景，此刻你在学习c++，在另一个平行时空中，另一个你在学习Java，两个互不干扰，当c++和Java都学习完之后，两个你进行合并，就能够花费更少的时间，学习到更多的技术。
对应到git来说，版本库中的HEAD指针指向master分支。master指向master分支中的最新的commitID。

通过.git中的结构，我们能够发现，每一次的提交记录都对应有上一次提交的commitID。所以可以将每次提交记录理解为线性的。

我们可以在master主分支再来开分支，这就涉及分支的创建，切换，合并操作。

创建切换合并删除分支

背景知识。
查看分支状态：git branch

现在只有一个master分支，那么前面的*号是什么意思呢？
HEAD指针并不是只能指向master分支，HEAD可以指向任何分支，当某个分支被HEAD指向时，该分支就是工作分支(add，commit的commitID在该分支上了)。

创建分支：git branch 分支名

当我们创建分支后，并打印master主分支和新分支的内容，发现两者的commitID相同。为什么呢？因为在当前的commitID的git版本下创建新的分支，那么该分支肯定和当前git版本是相同的，所以commitID相同。

切换分支：git checkout 分支名(注意不要带–，否则就是撤销修改的操作了)

此时HEAD指针肯定已经指向dev1了，当然，dev1肯定和master一样，都是指向对应分支的最新commitID。

创建 + 切换分支一步完成：git checkout -b 分支名(不存在的分支名)

合并分支：git merge 分支名

需要注意的是，如果想要将分支a合并到master分支，应该先切换到master分支，反之。

合并之后我们能够发现master指针和dev指针指向了同一个commitID，这就导致了无法区分是merge上去的还是刚创建的dev分支。解决方法我们放到后面的合并模式来谈

删除分支：git branch -d 分支名
当分支已经没用时，就删，没必要浪费空间
条件：该分支已经merge到master主分支了，所以此时该分支就已经没用了。

需要注意的点是删除a分支，此时HEAD一定不要指向a分支，需要切换分支。

合并冲突

情景：当创建分支a后，在分支a中提交了commitID，同时在master主分支也提交了commitID，即我们要合并的两个分支都提交了新的commitID，就会导致合并冲突。因为在同一个位置代码合并之后不知道是放置分支a对应位置的代码，还是master主分支对应位置的代码。

合并冲突只能够程序员来手动解决。我们来看一下ReadMe文件内部是什么

当我们手动解决冲突之后，我们一定要重新add + commit，而且一定要，才能解决合并冲突问题。
来看图像：

关键：我们手动解决合并冲突后，发现dev和master指向的不是同一个commitID了

合并模式

在git中，合并模式分为fast-forward(ff)模式，和no-fast-forward(no-ff)模式。
ff模式发生的情况就是在上方合并时只有一条分支提交commitID。
no-ff模式发生的情况就是合并时两条分支都提交commitID。

ff模式有个缺点，无法区分是merge合并时还是分支刚创建时，因为两种情况dev1和master分支指向的commitID都相同。但是，no-ff模式dev和master指向的commitID不相同，所以，要求不能使用ff模式合并，要求使用no-ff的方式合并。

指令：git merge --no-ff -m “xxxx” 被合并的分支名

来看操作以及效果：

我们发现dev2和master的commitID不相同了。

其实底层是怎样做的呢？就是dev2和master的commitID相同时，在master分支在提交一个commitID即可。这样一眼就可以看出该commitID是合并而来的。

同时我们可以通过git log --graph --pretty=oneline --abbrev-commit指令来以图像化的形式观察commitID。

同样的，也可以使用该指令来观察文章之前的分支结构

分支策略

这里我们提到的是概念。
master分支运用场景：线上环境（如app，小程序），此时用户是可以访问到的。所以要求必须稳定。
dev分支等：未测试的开发人员提交的代码，不稳定，存在bug。

结论：利用分支进行多人协作+在分支上进行研发，不能在master主分支修改(一定不能再master主分支上修改)

bug分支

情景：当我们在自己的分支上正在研发时，突然发现在master主分支上发现bug，我们该如何做来修改master主分支的bug，同时保证自己分支的代码不被丢弃呢？

1：将dev分支中未开发完的代码放到stash区域先存储起来，防止丢失。
git stash
细节：该指令只能够将工作区已经被git追踪的文件的修改放大stash区域。
扩展指令：
git stash list：看存储区(stash)存了哪些东西
git stash pop：取出存储区(stash)存的内容

我们通过观察 .git的目录结构，就会发现新增了stash存储区域

2:在master主分支创建fix_bug分支，在该分支中完成bug修改，随后合并到主分支


3：回到正在开发的分支，在stash区域拿出先前已经开发的代码，为了防止合并冲突，在dev分支合并master分支，在本地分支解决手动修改冲突问题
细节：合并冲突不要直接到master主分支上去改，防止造成修改错误

此时由于bugmaster分支有新的commitID，dev2分支开发完成之后也会有新的commitID，肯定会造成合并冲突。但是选择在dev2分支解决冲突。

手动解决冲突后一定要在commit一下。

4：bug修改好后,最后将dev分支合并到master分支
注意使用no-ff的方式合并。

这样就完成了bug分支的处理

强制删除分支

当我们正在进行本地分支开发时，发现该功能不需要了，所以需要删除该分支。但是该分支还没有被merge。
既然是删除分支，HEAD肯定不能指向将要被删除的分支上。
指令 ：git branch -D 分支名