集中式工作流
基于master分支开发
流程:
- 创建origin/master分支
- 协作开发者A、B把origin/master 分支clone到本地
- 协作开发者A、B在本地master分支进行开发
- A开发完push到远程master分支
- B开发完push到远程master分支
冲突处理
push时本地代码与远程master有分歧时推不上去,用git pull --rebase origin master
把远程master的代码与本地代码进行合并同步,如果merge的过程中存在CONFLICT,解决完conflict再push到master。
重点
- 每次开发前都从origin/master 分支先pull一下
- 提交之前也 git pull --rebase
功能分支工作流
功能分支工作流开发工工作在特性分支开发,在最终合并到master之前不会影响master分支的代码,保证了master分支可以作为一个稳定的可发布版本。
流程
- 确定开发的功能后以master为基础创建一个功能分支 例如 dev
git checkout -b dev master
- 在特性分支上进行开发,开发之后push到中央仓库的功能分支,其他人也可以提交到该功能分支
- 该功能分支开发完成之后,提交一个pull request请求合并到master,项目成员进行讨论
- pull request合并后该分支删除
git checkout master git pull git pull origin dev git push
重点
- 功能分支与master主分支在同一个中央仓库
- pull request进行code review
- 互不影响,多个功能同时开发
- 合并分支的时候,加上 no-ff 参数
Git flow 工作流
Gitflow 工作流,扩展了集中式工作流与功能分支工作流。包含 开发分支devleop,特性分支 feature-xx,发行分支release-xx,维护分支 master,修复分支 hotfix
流程
- 项目创建的时候同时创建master和develop分支
- 项目成员clone把项目到本地
- 开发feature的时候以develop进行checkout
git checkout -b develop origin/develop
- feature 开发完后发起 pull request合并到到develop
- 版本开发完成后准备发行,以develop创建一个release-xx发行分支
- release发行完成,把release-xx合并到维护分支master,并打上tag标签
- 发行后修改bug,以master分支checkout一个hotfix-xx分支,修改后合并到master分支,同时要合并到develop分支。
重点
- 各分支的意义
- feature (多个) 主要是自己玩了,差不多的时候要合并回 develop 去。不与 master 交互。
- develop (同时间一个) 主要是和 feature 以及 release 交互
- release (同时间一个) 总是基于 develop,最后又合并回 develop。当然对应的 tag 要合并到 master 分支,生命周期短,仅是为了发布程序
- hotfix (同一时间一个) 总是基于 master,并最后合并到 master 和 develop。生命同期较短,用来修复 bug 或小粒度修改发布
- master (仅一个) 关联 tag 和发布
- 特性分支都是基于开发分支develop
- 发行分支创建好之后,要修改部分内容要往release分支合并
- 发行后的维护需要从master 进行checkout
Forking 工作流
把中央仓库fork到自己的代码仓库,在自己的代码仓库开发,完了之后提交pull request 合并到中央仓库的主分支
流程
- fork
- git remote add
- pull request
重点
- Forking工作流的一个主要优势是,贡献的代码可以被集成,而不需要所有人都能push代码到仅有的中央仓库中。
开发者push到自己的服务端仓库,而只有项目维护者才能push到正式仓库。
GitHub Flow
GitHub Flow 推荐做法是只有一个主分支 master,团队成员们的分支代码通过 pull Request 来合并到 master 上
GitHub Flow 模型简单说明
- 只有一个长期分支 master ,而且 master 分支上的代码,永远是可发布状态,一般 master 会设置 protected 分支保护,只有有权限的人才能推送代码到 master 分支。
- 如果有新功能开发,可以从 master 分支上检出新分支。
- 在本地分支提交代码,并且保证按时向远程仓库推送。
- 当你需要反馈或者帮助,或者你想合并分支时,可以发起一个 pull request。
- 当 review 或者讨论通过后,代码会合并到目标分支。
- 一旦合并到 master 分支,应该立即发布。
特色之 Pull Request
GitHub Flow 最大的特色就是 Pull Request 的提出,这是一个伟大的发明,它的用处并不仅仅是合并分支,还有以下功能:
-
可以很好控制分支合并权限。
-
分支不是你想合并就合并,需要对方同意呐
-
问题讨论 或者 寻求其他小伙伴们的帮助。
和拉个讨论组差不多,可以选择相关的人参与,而且参与的人还可以向你的分支提交代码,可以说,是非常适合代码交流了。 -
代码 Review 。
如果代码写的很烂,有了 pull request 提供的评论功能支持,准备好接受来自 review 的实时吐槽吧。当然你如果写的很棒,肯定也能被双击666的。
特色之 issue tracking 问题追踪
日常开发中,会用到很多第三方库,然后使用过程中,出现了问题,是不是第一个反应是去这个第三方库的 GitHub 仓库去搜索一下 issue ,看没有人遇到过,项目维护者修复了没有,一般未解决的 issue 是 open 状态,已解决的会被标记为 closed。这就是 issue tracking。
如果你是一个项目维护者,除了标记 issue 的开启和关闭,还可以给它标记上不同的标签,来优化项目。当提交的时候,如果提交信息中有 fix #1 等字段,可以自动关闭对应编号的 issue。
Gitlab flow
集百家之长,推荐使用
团队配合
一个版本划分为主线和辅线,A负责主线开发,B负责辅线和线上bug修复,下个版本互换,A负责辅线和线上bug修复,B负责主线开发