git多分支管理

1.Master

1.用途

• master分支是【主分支】，包含稳定的、已发布的生产代码。每次产品发布时，都会将代码合并到 master 分支。
• 此分支上的每个commit 都应该是一个发布版本，所以推荐从release分支合并过来

2.管理方法

• 合并分支，从仓库提交pull requests，一般情况是选择从release分支合并到master分支
• 紧急修复，git checkout -b hotfix/hotfix-login-password-check-failed master

2.Develop

1.用途

• 【开发分支】是所有功能开发的基础分支，用于集成各功能的开发成果
• 所有功能开发都应该基于开发分支展开

2.管理方法

• 获取最新代码，一般情况下开发分支代码是最新的，所以开发工作需要基于该分支开展
• 合并分支，所有功能分支开发完成后，都将合并到该分支

3.Feature

1.用途

• 【功能分支】，每个新功能的开发都应该在单独的功能分支上进行，以保持代码仓库的清晰和可维护性
• 每个功能开发完成后，应该将功能分支合并到开发分支中进行集成测试

2.管理方法

• 1.基于开发分支创建具体的功能分支
  • 1.功能分支应该见名知意，命名应该以feature开头
  • 2.功能分支最好以最小功能为单位，不要一个分支做很多事情，使得分支管理混乱
  • 3.比如：新增功能重置用户密码，命名如下：feature/reset-user-password

  git checkout -b feature/reset-user-password develop
  

• 2.重置密码功能开发完成，提交仓库

  git add .
  git commit -m "新增用户密码重置接口"
  

• 3.推送分支到远程仓库

  # 首次推送
  git push -u origin feature/reset-user-password
  # 后续直接提交（如果以最小功能单位创建分支，则每次提交被合并后都会被远程仓库删除，不会用到下面命令重复提交）
  git push
  

  • 严谨情况下在push前应该切到开发分支，拉取一次最新代码到本地，然后进行merge解决代码冲突，因为你不能保证在你开发此功能过程中，没有其他同时提交合并。如果他也恰好修改了你所用到的文件代码，而你又没有尝试merge解决冲突，那么在后续提交分支合并时就会出现冲突，被打回来，所以最好提前处理。
  • 如果是一个人开发，或者你确定不会有冲突，则可以忽略下面流程

    # 切回开发分支，拉取最新代码
    git checkout develop
    git pull origin develop# 尝试合并解决冲突
    git checkout feature/reset-user-password
    git merge develop
    

• 4.提交pull requests
  • 登录代码仓库，找到Pull Requests，新建Pull Requests
  • 源分支：选择你所提交的功能分支：feature/reset-user-password
  • 目标分支：选择开发分支：develop
• 5.一旦功能分支被合并，我们就可以删除本地分支

  git branch -d feature/reset-user-password
  

• 6.新功能的开发，再次重复1-5步骤

4.Release

1.用途

• 【发布分支】用于准备发布新版本，进行最后的测试和准备工作
• 从 develop 分支创建，准备就绪后合并到 master 和 develop 分支，并标记版本号。

2.管理方法

• 1.从开发分支拉取最新代码，保证拉取前本阶段所有任务已经全部完成，且所有人代码已经提交

  git checkout -b release/v1.0 develop
  

• 2.将最新代码打包，发送测试组进行完整的测试，测试中如果出现BUG，则重复Feature分支管理1-5步进行修复，也可以新建一个专门处理BUG的分支，例如：BugFix，流程和功能分支开发流程基本一致。

  # 如果有bug修复，修复完成后拉取最新代码，合并解决冲突
  git checkout release/v1.0
  # 修复问题...
  git commit -m "fix: 修复登录页面布局问题"# 合并到开发分支
  git checkout develop
  git merge release/v1.0
  

• 3.测试组测试通过后，发布稳定版本

  # 将发布分支合并到主分支
  git checkout master
  git merge --no-ff release/v1.0
  git push# 给发布分支打标签
  git tag -a v1.0.0 -m "Release version 1.0"
  git push origin v1.0  将tag推送到远程仓库
  # v<主版本>.<次版本>.<修订号>
  # 正式版：v1.0.0
  # 预发布版：v1.0.0-rc1
  # 测试版：v1.0.0-beta3
  # 热修复版：v1.0.1-hotfix# 合并回 develop 分支（包含所有修复）
  git checkout develop
  git pull
  git merge --no-ff release/v1.0
  git push# 删除发布分支
  git branch -d release/v1.0
  git push origin --delete release/v1.0
  

5.Hotfix

1.用途

• 【紧急修复分支】当生产环境出现紧急问题需要立即修复时，可以创建紧急修复分支进行处理
• 紧急修复分支应当基于master分支创建
• 修复完成后，应该将紧急修复分支合并到主分支master和开发分支develop中，确保问题得到解决

2.管理方法

• 1.创建紧急修复分支

  git checkout -b hotfix/fix-password-encrypt-failed master
  

• 2.合并

  # 处理bug
  ...# 合并分支到master
  git checkout master
  git merge hotfix/fix-password-encrypt-failed
  git tag -a v1.0.1 -m "Hotfix version 1.0.1"
  git push origin v1.0.1git checkout develop
  git merge hotfix/fix-password-encrypt-failed
  git branch -d hotfix/fix-password-encrypt-failed