贯穿整个开发周期,master和develop分支是一直存在的,master分支可以被视为稳定的分支,而develop分支是相对稳定的分支,特性开发会在feature分支上进行,发布会在release分支上进行,而bug修复则会在hotfix分支上进行。
master分支
- 主分支
- 保持稳定
- 不允许直接往这个分支提交代码,只允许往这个分支发起merge request
- 只允许release分支和hotfix分支进行合流
develop分支
- 开发分支
- 相对稳定的分支
- 用于日常开发,包括代码优化、功能性开发
feature分支
- 特性分支
- 从develop分支拉取,用于下个迭代版本的功能特性开发
- 功能开发完毕合并到develop分支
release分支
- 发布分支
- 从develop分支拉取
- 用于回归测试,bug修复
- 发布完成后打tag并合入master和develop
hotfix分支
- 热更新分支
- 从develop分支拉取
- 用于紧急修复上线版本的问题
- 修复后打tag并合入master和develop
大家可能会发现我们这个跟标准的Gitflow工作流有些差别,其实也没有什么标准不标准的,前面说到要结合团队的实际情况,我们团队对于目前所采用的工作方式都是达成共识的,所以有一些差异并没有关系。
说了这么久,还没有一句git命令,那就让大家感受一下吧(感谢Bugly小色熊整理):
1). 首先将远程代码拉取到本地
git clone xxx
git checkout -b develop origin/develop
2).新建feature分支
git checkout -b feature
3).多人在feature上开发,如果中途需要将develop的变更合入feature,所有人需要将本地的代码变更提交到远程
git fetch origin
git rebase origin/feature
git push origin feature
然后由feature负责人rebase develop分支,删除原来feature分支,重新新建feature分支;
git fetch origin
git rebase origin/feature
git rebase develop
git push origin :feature
git push origin feature
这样可以保证feature保持线性变更;
4).feature开发完成后,所有人需要将本地的代码变更提交到远程
git fetch origin
git rebase origin/feature
git push origin feature
然后由feature负责人rebase develop分支,然后将feature分支合入develop,删除feature;
git fetch origin
git rebase origin/feature
git rebase develop
git checkout develop
git merge feature
git push origin :feature
这样可以保证develop保持线性变更,各feature的变更完整可追溯;
5).合入feature后拉出对应的release/feature分支,后续bug修复在release/feature上
git checkout develop
git checkout -b release/feature
release/feature分支的同步合并与feature分支相同
6).release/feature分支bug修复完成后,拉取对应的tag推送远程进行发布
git tag -a v1.0 -m 'feature发布'
git push origin v1.0
之后将release/feature合入develop分支,然后删除
git rebase develop
git checkout develop
git merge release/feature
git push origin :release/feature
7).发布完成后将release合入master分支,保证master为最新稳定版本(实际操作为发起merge request)
参考文章:https://juejin.im/post/5a014d5f518825295f5d56c7
https://blog.csdn.net/wwj_748/article/details/55226044