git使用

idea中使用git

https://blog.csdn.net/dpnice/article/details/80827047

Git的分支类型

1、Master分支

一个项目的代码库应该有且只有一个主分支，所有提供给用户使用的正式版本，都是在这个主分支上，我们称为Master分支。

2、Develop分支

日常使用的开发分支。这个分支可以用来生成代码的隔夜版本，如果开发功能测试完成后，想正式对外发布，就在Master分支上，对Develop分支进行“合并”（Merge）。

3、临时分支

除了日常开发设置分支外，还有一种临时分支，以应对一些特定目的的版本开发。

• 功能分支：它是为了开发某种特定的功能，从Develop分支上分出来的。开发完成后，合并到Develop分支上。其命名规范：feature-*
• 预发布分支：在发布到正式版本之前，我们可能需要有一个预发布版本进行测试。预发布分支是从Develop分支上分出来的，预发布结束后，必须合并到Develop分支和Master分支。其命名规范：release-*

• 修补Bug分支：软件正式发布后，出现一些Bug，这时就需要创建一个分支，来进行Bug修复。修复Bug分支是从Master分支上分出来的，修补结束后，在合并到Develop和Master分支。其命名规范：fixbug-*

• Git的分支使用

  1、develop分支(develop)

  • Git创建develop分支
    develop分支是从master分支中分出来的，其命令：

  git checkout -b develop master
  

  • 将develop分支发布到master分支
  1. # 切换到master分支
  2. git checkout master
  4. # 对develop分支进行合并
  5. git merge -- no-ff develop

  Git Merge在默认情况下是执行“快进式合并”，也就是将master分支直接指向develop分支，并没有建立新的节点。
  为了保证版本演进的清晰，我们一般采用正常合并，即使用--no-ff参数，master分支上生成一个新节点。

  2、功能分支(feature-*)

  • Git创建功能分支
    feature分支是虫develop分支中分出来的，其命令：
  1. # x 版本号，如：1.1
  2. git checkout -b feature-x develop
  • 将feature分支合并到develop分支
    开发完成后，需要将功能分支合并到开发分支，其命令：
  1. git checkout develop
  2. git  merge  no-ff feature-x 
  • 删除功能分支

  git branch -d feature-x
  

  3、预发布分支(release-*)

  • Git创建预发布分支
    预发布分支是从develop分支中分出来的，其命令：
  1. # x 版本号，如：1.1
  2. git checkout -b release-x develop
  • 将预发布分支合并到master分支
    预发布分支测试没有问题后，需要合并到master分支，其命令：
  1. git checkout master
  2. git merge -- no-ff release- x
  4. # 对合并生成的新节点，做一个标签(打上版本标签)
  5. git tag -a  x
  • 删除预发布分支

  git branch -d release-x
  

  4、修复Bug分支(fixbug-*)

  • Git创建修复Bug分支
    修复Bug分支是从master分支中分出来的，其命令：
  1. #  x版本号，如：1 .1 .1
  2. git  checkout  -b  fixbug-x  master
  • 将修复Bug分支合并到master分支
    bug修复完成后，需要合并到master分支，其命令：
  1. git checkout master
  2. git  merge  -- no -ff fixbug-x 
  3. git tag x
  • 将修复bug分支合并到develop分支
  1. git checkout develop
  2. git  merge  -- no -ff fixbug-x
  • 删除修复bug分支

  git branch -d fixbug-x
  

  总结

  在Git系统中合并代码有git merge 和git rebase两种方式。为什么我们不讲git rebase呢，因为它不常用。

  • rebase的优势在于项目的历史提交信息非常完整。
  • rebase的劣势在于安全性和可跟踪性。
  • rebase的黄金法则：==绝对不要在公共分支上使用它==。