git工作流具体操作流程
2017-03-26 12:22
197 查看
集中式工作流
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. 具体操作流程
创建一个新的分支(develop,release,feature…),同步到远程仓库:git branch develop
git push -u origin develop
其他开发者拷贝分支到本地,跟踪远程仓库的状态:
git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop
开发这创建自己需要的分支,进行日常功能开发(继承自develop)
git checkout -b some-feature develop
开发完成,合并分支
如果使用pull requests,则发起一个合并请求,由创建者进行合并
也可以在本地同步,合并,再push上去
git checkout develop
git merge some-feature
git push
合并成功后,该分支不再需要,直接删除:
git branch -d some-feature
正式发布的分支,可以加上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/
相关文章推荐
- GitFlow工作流常用操作流程
- GitFlow工作流常用操作流程
- Activiti工作流框架学习(二)——使用Activiti提供的API完成流程操作
- git-新手入职必备操作流程
- Git发布本地项目至仓库命令行操作流程
- Git客户端图文详解如何安装配置GitHub操作流程攻略
- my project 中git使用过程(基本操作流程)
- 项目管理---git----快速使用git笔记(七)------coding.net项目管理多人操作的流程规范--合并代码审核
- 【代码管理】GitHub超详细图文攻略 - Git客户端下载安装 GitHub提交修改源码工作流程 Git分支 标签 过滤 Git版本工作流
- GitHub超详细图文攻略 - Git客户端下载安装 GitHub提交修改源码工作流程 Git分支 标签 过滤 Git版本工作流
- Git+Github的整体流程(单人操作)
- Git客户端图文详解如何安装配置GitHub操作流程攻略
- Git客户端图文详解如何安装配置GitHub操作流程攻略
- Git操作流程
- MapInfo中图斑的具体操作流程
- github上传本地项目具体操作流程及问题解决
- GIT第二讲的基本操作流程和常用命令
- git相关工作流。利用git开发软件工作流程
- Git的简介与Git详细操作流程
- GitHub超详细图文攻略 - Git客户端下载安装 GitHub提交修改源码工作流程 Git分支 标签 过滤 Git版本工作流