git工作流具体操作流程

集中式工作流

1. 工作方式概述

  • 集中式工作流以中央仓库(可以理解为远程仓库)作为项目所有修改的单点实体,所有修改都以中央仓库为基准。
  • 开发者开始先克隆中央仓库。在自己的项目拷贝中,像SVN一样的编辑文件和提交修改;但修改是存在本地的,和中央仓库是完全隔离的。开发者可以把和上游的同步延后到一个方便时间点。
  • 要发布修改到正式项目中,开发者要把本地分支的修改push到远程仓库中

2. 冲突解决原则

  • 中央仓库代表了正式项目,所以提交历史应该被尊重且是稳定不变的。
  • 如果开发者本地的提交历史和中央仓库有分歧,应该使用rebase在本地解决冲突,解决完成冲突之后在push上去,

3. 具体过程

  • git init: 首先在远程建立一个统一的中央仓库
  • git clone :开发者通过克隆远程仓库进行新增功能操作
  • git fetch: 在开发者完成自己的功能,提交自己功能修改到中央库前,需要先fetch在中央库的新增提交;
  • git rebase: 自己提交到中央库提交历史之上:
  • 详情看图片
    这里写图片描述
    • 开发者A从C2的位置clone到本地仓库,在本地增加了C5,C6两个commit
    • 这个过程中,远程origin分支其他开发者B push了C3,C4两个commit
    • 此时A需要进行 git fetch 获取远程仓库的最新状态
      这里写图片描述
    • 进行git rebase,首先丢弃C2之后的commit,换成远程的C3,C4,之后创建新的C5‘,C6’添加在C4之后,
    • 如果这个过程中,出现冲突,Git会停止rebase并会让你去解决冲突,按照以下步骤解决:
    • 在本地修改文件解决完成冲突
    • 用”git add”命令去更新这些内容的索引(index)
    • 然后,你无需执行 git-commit,只要执行 git rebase –continue,就可以继续rebase操作

Gitflow工作流

1. 流程示意图

gitflow 工作流定义了一个围绕项目发布的严格分支模型。首先来直观感受一下:
这里写图片描述

2. 分支概述

  • master分支
    • 用来放置已经完整开发的正式版本的分支,只有测试完毕,要用于发布的版本才会提交到master分支。
    • 我们还能为每个master设置tag,用来标记版本号
  • develop分支
    • 开发功能集成分支,这是开发者集成所使用的分支,每个开发者修复bug,新增的feature,都会首先提交到develop分支进行集成和测试
  • feature分支
    • 功能特性分支,开发者日常开发时维护增加commit的分支,
    • 他继承自develop分支,而不是master,
    • 每个feature分支需要有一个明确的开发功能,命名也以这个开发功能进行,比如feature-login,功能完成后,集成到develop中
  • release分支
    • release分支,属于发布前的预备分支,用于当产品功能完善之后,在合并到master正式发布之前所做的一些准备工作。这个分支只应该做Bug修复、文档生成和其它面向发布任务,从这个时间点开始之后新的功能不能再加到这个分支上。
    • 一旦对外发布的工作都完成了,发布分支合并到master分支并分配一个版本号打好Tag。
    • 同时,release分支的内容合并到develop中
    • 命名规则:release-* 或 release/*
    • 好处:使用一个用于发布准备的专门分支,使得一个团队可以在完善当前的发布版本的同时,另一个团队可以继续开发下个版本的功能
  • hotfix分支:
    • 维护分支,为Bug修复使用专门分支,让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。
    • 这是唯一可以直接从master分支fork出来的分支。修复完成,修改应该马上合并回master分支和develop分支(当前的发布分支),master分支应该用新的版本号打好Tag。

3. 具体操作流程

  1. 创建一个新的分支(develop,release,feature…),同步到远程仓库
    • git branch develop
    • git push -u origin develop
  2. 其他开发者拷贝分支到本地,跟踪远程仓库的状态
    • git clone ssh://user@host/path/to/repo.git
    • git checkout -b develop origin/develop
  3. 开发这创建自己需要的分支,进行日常功能开发(继承自develop)
    • git checkout -b some-feature develop
  4. 开发完成,合并分支
    • 如果使用pull requests,则发起一个合并请求,由创建者进行合并
    • 也可以在本地同步,合并,再push上去
    • git checkout develop
    • git merge some-feature
    • git push
    • 合并成功后,该分支不再需要,直接删除:
    • git branch -d some-feature
  5. 正式发布的分支,可以加上tag:
    • git tag -a 0.1 -m “Initial public release” master
    • git push –tags

参考文章

《git命令之git rebase 的用法》http://blog.csdn.net/wangjia55/article/details/8490679
《Git工作流指南:集中式工作流》 http://blog.jobbole.com/76847/
《Git工作流指南:Gitflow工作流》 http://blog.jobbole.com/76867/

发布了4 篇原创文章 · 获赞 15 · 访问量 2万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览