Git--05--说明GIT分支

GIT分支

分支在GIT中相对较难，分支就是科幻电影里面的平行宇宙，如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，我们就需要处理一些问题了！

git分支中常用指令：

# 列出所有本地分支
git branch

# 列出所有远程分支
git branch -r

# 新建一个分支，但依然停留在当前分支
git branch [branch-name]

# 新建一个分支，并切换到该分支
git checkout -b [branch]

# 合并指定分支到当前分支
$ git merge [branch]

# 删除分支
$ git branch -d [branch-name]

# 删除远程分支
$ git push origin --delete [branch-name]
$ git branch -dr [remote/branch]

IDEA中操作


• 如果同一个文件在合并分支时都被修改了则会引起冲突：解决的办法是我们可以修改冲突文件后重新提交！选择要保留他的代码还是你的代码！
• master主分支应该非常稳定，用来发布新版本，一般情况下不允许在上面工作，工作一般情况下在新建的dev分支上工作，工作完后，比如上要发布，或者说dev分支代码稳定后可以合并到主分支master上来。

git分支管理策略

1 总览

git 的分支整体预览图如下：

主要包含下面几个分支：

master：git默认主分支（这里不作操作）。

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

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

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

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

• bugfix：线上 bug 修复分支。

主分支

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

• stable分支：用来发布，管理着多个稳定的版本。

• develop分支：就是我们日常开发的分支.

使用这两个分支就具有了最简单的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题后，则将 develop 分支的代码合并到 stable分支并发布。

在开发中如果我们只用主分支来进行管理，那么就会造成develop发布完成之后才能进行下一迭代的开发，开发会比较缓慢。如果线上代码发现bug之后，很难进行bug修复。

针对以上问题，建立辅助分支就能完美的解决。

辅助分支

辅助分支主要有一下几个：

1. feature分支
2. release分支
3. bugfix分支

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

1 feature分支

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

2 release分支

• release分支作为预发布分支，release 分支从 develop 分支 fork 出来，最终会合并到 develop 分支和stable 分支，合并到 stable分支上就是可以发布的代码了。
• 为什么我从develop分支fork出来，还要合并到develop分支中呢？因为我们在release分支上难免会有bug产生，修复bug也是在release分支上，所以必须要合并到develop分支。
  

3 bugfix分支

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

Tag标签

• 在我们用git做版本管理的时候，每次提交代码都会生成唯一标识本次提交的编码，对于这个编码我们直观的看是没有任何意义的。为了很好标识每个版本的变化，我们会在每个版本发布的同时打上一个tag，通常和版本名称相同。
• 比如我们开发了V1.0、V1.1，不同的版本对应不同的代码，当我们在V1.1上面发现bug时，但并不确定V1.0是否存在bug，那我们怎么确认V1.0存在bug呢？怎么知道哪些提交的代码属于V1.0？此时tag就很有用了。我们在发布V1.0和V1.1这两个版本时，分别为这两个版本加上tag1.0和tag1.1，当我们需要验证V1.0是否存在bug时，切换到tag1.0上就可以验证了。