企业官网建设流程全解析

Git分支管理

1.1 分支介绍

Git默认分支master，也就是主分支。我们所做的commit会在master分支上自动移动，在多次提交操作之后，master分支指向最后哪个commit object（提交对象链）。

Git的“master”分支并不特殊，我们建立的其他develop分支可以说和它完全相同。之所以每个仓库都有masteri分支，只因为git init初始化交给git管理之后就会创建master分支。

1.2 分支创建

通过

·git branch #来查看和创建分支。

创建标签记在HEAD指针所指向的提交点tag（就是当前所在分支）

·git branch 分支名 #可以创建一个新的分支 ·git branch #可以查看当前存在分支和我们处于哪个分支

这里可以看见我们有两个分支，一个dev 一个master。

绿色的master和上方括号中蓝色的master可以看出我们正处于master主分支。

·git checkout 分支名 #切换到xx分支

·git checkout -b 分支名 #创建分支和切换同时完成

我们在dev2分支创建A.txt文件并提交，我们会发现dev2可以看见这个文件，而master无法看见这个文件

1.3 分支删除

1.不能删除自己所在分支

可见在dev2分支里删除dev2分支会报错

可以切换到master删除一个合并后的或者没有发生变化的分支

2.如果一个分支发生了变化那就不能删除了

此时可以强制删除

·git branch -D dev2

1.4 分支合并

此时我们回到刚才创建并提交了A.txt文件之后的dev2分支

然后尝试让dev2分支合并master分支上

git merge dev2

此时我们再查看文件

可以看见原本在master分支里看不到的 A.txt出现了，证明dev2已经和master合并了

1.5 分支的本质

master指向的是提交

HEAD是指向当前的分支，当前在哪个分支就指向哪个分支

第二张图上我们可以看到创建了dev分支，当我们切换到dev分支的时候HEAD就会指向dev

当我们进入.git文件夹查看HEAD内容就可以看到，所处分支不同的内部文件指向就不同。

Master分支

Dev2分支

Git的分支与svn不同，svn是整体拷贝一份分支，而git用的指针。

如果dev发生修改，dev的版本就会向后移动

在master分支上如果合并就会出现下面的图

1.6 分支的冲突

冲突问题发生的演示：

1.先准备一个干净文件test.txt

echo "我是主分支内容" > test.txt git add test.txt git commit -m "master：初始化test.txt"

2.创建并切换到新分支

git checkout -b dev

3.在dev分支修改文件

echo "dev 分支修改了这里" > test.txt git add test.txt git commit -m "dev：修改内容"

4.切回master分支

git checkout master

5.master也修改同一个文件的同一行（制造冲突）

echo "master 也修改了这里" > test.txt git add test.txt git commit -m "master：也修改了内容"

6.现在合并dev到master->冲突出现了

git merge dev

可以看见出现了冲突

1.7冲突问题的解决

1.编辑文件，删掉冲突符号

现在我们打开test.txt文件

·<<<<<<< HEAD：当前分支（master）的内容

·=======：分隔线

·>>>>>>> dev：被合并分支（dev）的内容

2.手动编辑文件，删除冲突标记，保留想要的内容

可以保留master的内容

也可以保留dev的内容

或者写一个合并后的新内容

比如：合并后的最终内容（保留了两个分支的修改）

3.标记冲突已经解决，并完成提交

把修改后的文件加入暂存区

git add test.txt

提交合并结果

git commit -m "解决了test.txt的分支冲突"

我们可以通过图形来查看冲突的日志提交

git log --graph

1.8 git stash

做什么用的？

比如说在做项目的时候，老板突然说先改一个bug或者是先上线一个小功能。

我们现在修改的工作区代码就可以通过 git stash 放入栈里边存起来。

演示：

我们先在master分支上修改A.txt 添加一行数据

使用 git stash将暂存区的文件隐藏了起来，可以看见现在干净了

现在可以把藏起来的代码拿回来

git stash pop

git list #查看所有stash记录 git stash apply #恢复stash但保留记录 git stash clear #删除所有stash记录

1.9 分支管理策略

Master：git默认主分支（这里不做操作）

Stable：稳定分支，替代master，主要用来版本发布。

Develop：日常开发分支，该分支正常保存了开发的最新代码

Feature：具体的功能开发分支，只与develop分支交互。

Release：release分支可以认为是stable分支的为测试版本。比如说某一期的功能全部开发完成，那么就将develop分支合并到release分支，测试没有问题并且到了发布日期就合并到stable分支，进行发布。

Bugfix：线上bug修复分支

1.主分支

因为master分支我们不操作，所以stable和develop这两个主分支来讲解。

Stable分支：用来发布，管理多个稳定版本

Develop分支：就是我们日常开发的分支

使用这两个分支就具有了最简单的开发模式：

Develop分支用来开发功能，开发完成并测试没有问题后，则将develop分支的代码合并到stable分支并发布。

2.辅助分支

通过这些分支，我们可以做到：团队成员之间并行开发，增加新功能更加容易，可以同时进行开发和版本发布，线上bug修复等。

3.feature分支

Feature分支用来开发具体功能，一般基于develop分支，最后完成功能后在合并到develop分支。

比如，目前针对develop进行功能开发，在开发的过程中会有紧急需求需要发开，且在本次版本发布时间之前要能测试完成。我们可以基于之前稳定版本另开一个feature分支来做紧急需求的开发，发布并进行测试，完成之后合并到develop分支上。

4.release分支

Release分支作为预发布分支，release分支从develop分支fork出来，最终会合并到develop分支和stable分支，合并到stable分支上就是可以发布的代码了。

为什么我从develop分支fork出来还要合并到develop分支中呢？

因为我们在release分支上难免会有bug产生，修复bug也是在release分支上，所以必须要合并到develop分支。

5.bugfix分支

Bugfix分支用来修复线上bug。当线上代码出现bug时，我们基于stable分支开发一个bugfix分支合并到stable分支并进行发布，同时develop分支作为最新最全的代码分支，bugfix分支也需要合并到develop分支上去。