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
- 1.功能分支应该见名知意,命名应该以
- 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