你好,游客 登录 注册 搜索
背景:
阅读新闻

GitHub Flow & Git Flow 基于Git 的两种协作开发模式

[日期:2016-09-14] 来源:Linux社区  作者:sloong [字体: ]

介绍基于Git 两种协作开发模式

对于Github 一些好用的特殊操作技巧 ,可以见GitHub 特殊操作技巧 和Git的基本操作  http://www.linuxidc.com/Linux/2016-09/135184.htm

GitHub Flow

GitHub Flow —— 以部署为中心的开发模式,通过简单的功能和规则,持续高速 安全地进行部署。在实际开发中往往一天之内会实施几十次部署,而支撑这一切的,就是足够简单的开发流程以及完全的自动化。

  1. 令master 分支时常保持可以部署的状态
  2. 进行新的作业时要从master 分支创建新的分支,新分支名称要具有描述性
  3. 2新建的本地仓库分支中进行提交
  4. 在Github 端仓库创建同名分支,定期push
  5. 需要帮助、反馈,或者branch已经准备merging时,创建Pull Request,以Pull Request 进行交流
  6. 让其他开发者进行审查,确认作业完成后与master分支进行合并(合并的代码一定要测试
  7. 与master分支合并后,立刻部署

使用Github Flow 的前提条件

  • 团队规模最好控制在15-20人之内,具体见 how-github-works
  • 部署作业完全自动化。必须自动化,一天之类需要多次部署
    • 使用部署工具(Capistrano,Mina,Fabric,Webistrano,Strano等),让部署时所需的一系列流程自动化。
    • 通过Web界面进行部署,Capistrano 等部署工具需要命令执行操作,开发者以外的人很难实施部署
    • 导入开发时注意事项:随着团队人数的增多及成熟度的提高,开发速度会越来越快。往往一个部署尚未完成,另一名开发者就已经处理完下一个pull request,开始实施下一个部署。在这种情况下,一旦正式环境出现问题,很难分辨哪个部署造成了影响。为了应对该情况,建议在部署实施过程中通过工具加锁。
    • Git Hook 自动部署
  • 重视测试
    • 让测试自动化
    • 编写测试代码,通过全部测试
    • 维护测试代码

Git Flow

荷兰程序员 Vincent Driessen 曾发表了一篇博客,让一个分支策略广为人知。具体流程见下图(引用该博客的一幅图片)

这一流程最大的亮点是考虑了紧急Bug的应对措施,整个流程显得过于复杂,所以在实施该方案前,需要对整个开发流程进行系统的学习。也需要借助Git flow 等工具的辅助。

GitHub 教程系列文章: 

通过GitHub创建个人技术博客图文详解  http://www.linuxidc.com/Linux/2015-02/114121.htm

GitHub 使用教程图文详解  http://www.linuxidc.com/Linux/2014-09/106230.htm 

使用 GitHub / GitLab 的 Webhooks 进行网站自动化部署  http://www.linuxidc.com/Linux/2016-06/131993.htm

多个GitHub帐号的SSH key切换 http://www.linuxidc.com/Linux/2016-05/131080.htm

如何在同一台电脑上使用两个GitHub账户 http://www.linuxidc.com/Linux/2016-05/131079.htm

利用GitHub搭建个人Maven仓库  http://www.linuxidc.com/Linux/2016-04/130197.htm

一分钟认识GitHub http://www.linuxidc.com/Linux/2015-11/125089.htm

分享实用的GitHub 使用教程 http://www.linuxidc.com/Linux/2014-04/100556.htm 

下面根据上图,按块说明:

master 分支和 develop分支

在Git Flow 中,这两个分支至关重要,它们会贯彻整个流程始终,绝对不会被删除。

master 分支

master 分支时常保持着软件可以正常运行的状态。由于要维护这一状态,所以不允许开发者直接对master 分支的代码进行修改和提交。

其他分支的开发工作进展到可以发布的程度后,将会与master分支进行合并,并且这一合并只在发布成品时进行。发布时将会附加版本编号的Git标签。

develop分支

develop分支是开发过程中代码中心分支。与master 分支一样,这个分支也不允许开发者直接进行修改和提交。

程序员要以develop分支为起点新建feature 分支,在feature 分支中进行新功能的开发或者代码的修正。也就是说develop分支维系着开发过程中的最新代码,以便程序员创建feature分支进行自己的工作。

在feature 中工作

feature 分支以develop分支为起点,是开发者直接更改代码发送提交的分支。开发流程:

  1. 从develop分支创建feature分支
  2. 从feature分支中实现目标功能
  3. 通过Github 向develop发送pull request
  4. 接受其他开发者审核后,将Pull Request合并至develop分支

具体指令:

$ git checkout develop
$ git pull
$ git flow feature start add-user //add branch feature/add-user
$ git branch
// feature/add user  start commit commit ....
$ git push orgin feature/add-user
//到github 上去代码审查,切到develop分支,进行pull request 
$ git checkout develop
$ git pull // 当feature/add-user 合并到 develop后,本地develop 需要更新到最新状态

注意,默认状态是pull request 到master。这时需要手动切换到develop分支,再进行pull Request 操作。
如果采用该开发策略,那么可以在setting 中 Option 中,修改Default Branch 为 develop ,这样就省去了手动修改的麻烦。

与develop分支合并后,已经完成工作的feature分支可以在适当的时机删除

更多详情见请继续阅读下一页的精彩内容http://www.linuxidc.com/Linux/2016-09/135185p2.htm

linux
相关资讯       GitHub Flow  Git Flow  Git 协作开发模式 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款