没有合适的资源?快使用搜索试试~ 我知道了~
深入理解学习Git工作流(git-workflow-tutorial)
3 下载量 12 浏览量
2021-02-25
20:10:55
上传
评论
收藏 744KB PDF 举报
温馨提示
工作流其实不是一个初级主题,背后的本质问题其实是有效的项目流程管理和高效的开发协同约定,不仅是Git或SVN等VCS或SCM工具的使用。这篇指南以大家在SVN中已经广为熟悉使用的集中式工作流作为起点,循序渐进地演进到其它高效的分布式工作流,还介绍了如何配合使用便利的PullRequest功能,体系地讲解了各种工作流的应用。行文中实践原则和操作示例并重,对于Git的资深玩家可以梳理思考提升,而新接触的同学,也可以跟着step-by-step操作来操练学习并在实际工作中上手使用。关于Git工作流主题,网上体系的中文资料不多,主要是零散的操作说明,希望这篇文章能让你更深入理解并在工作中灵活有效地使用
资源推荐
资源详情
资源评论
深入理解学习深入理解学习Git工作流(工作流(git-workflow-tutorial))
一、译序
工作流其实不是一个初级主题,背后的本质问题其实是有效的项目流程管理和高效的开发协同约定,不仅是Git或SVN等VCS
或SCM工具的使用。
这篇指南以大家在SVN中已经广为熟悉使用的集中式工作流作为起点,循序渐进地演进到其它高效的分布式工作流,还介绍
了如何配合使用便利的Pull Request功能,体系地讲解了各种工作流的应用。
行文中实践原则和操作示例并重,对于Git的资深玩家可以梳理思考提升,而新接触的同学,也可以跟着step-by-step操作来操
练学习并在实际工作中上手使用。
关于Git工作流主题,网上体系的中文资料不多,主要是零散的操作说明,希望这篇文章能让你更深入理解并在工作中灵活有
效地使用起来。
PS:
文中Pull Request的介绍用的是Bitbucket代码托管服务,由于和GitHub基本一样,如果你用的是GitHub(我自己也主要使用
GitHub托管代码),不影响理解和操作。
PPS:
本指南循序渐进地讲解工作流,如果Git用的不多,可以从前面的讲的工作流开始操练。操作过程去感受指南的讲解:解决什
么问题、如何解决问题,这样理解就深了,也方便活用。
Gitflow工作流是经典模型,体现了工作流的经验和精髓。随着项目过程复杂化,会感受到这个工作流中深思熟虑和威力!
Forking工作流是协作的(GitHub风格)可以先看看Github的Help:Fork A Repo和Using pull requests 。照着操作,给一个
Github项目贡献你的提交,有操作经验再看指南容易意会。指南中给了自己实现Fork的方法:Fork就是服务端的克隆。在指南
的操练中使用代码托管服务(如GitHub、Bitbucket),可以点一下按钮就让开发者完成仓库的fork操作。
:see_no_evil: 自己理解粗浅,翻译中不足和不对之处,欢迎建议(提交Issue)和指正(Fork后提交代码)!
二、Git工作流指南
:point_right: 工作流有各式各样的用法,但也正因此使得在实际工作中如何上手使用变得很头大。这篇指南通过总览公司团队
中最常用的几种Git工作流让大家可以上手使用。
在阅读的过程中请记住,本文中的几种工作流是作为方案指导而不是条例规定。在展示了各种工作流可能的用法后,你可以从
不同的工作流中挑选或揉合出一个满足你自己需求的工作流。
2.1 集中式工作流
如果你的开发团队成员已经很熟悉Subversion,集中式工作流让你无需去适应一个全新流程就可以体验Git带来的收益。这个
工作流也可以作为向更Git风格工作流迁移的友好过渡。
转到分布式版本控制系统看起来像个令人生畏的任务,但不改变已用的工作流你也可以用上Git带来的收益。团队可以用和
Subversion完全不变的方式来开发项目。
但使用Git加强开发的工作流,Git有相比SVN的几个优势。
首先,每个开发可以有属于自己的整个工程的本地拷贝。隔离的环境让各个开发者的工作和项目的其他部分修改独立开来
——
即自由地提交到自己的本地仓库,先完全忽略上游的开发,直到方便的时候再把修改反馈上去。
其次,Git提供了强壮的分支和合并模型。不像SVN,Git的分支设计成可以做为一种用来在仓库之间集成代码和分享修改的
『失败安全』的机制。
2.1.1 工作方式
像Subversion一样,集中式工作流以中央仓库作为项目所有修改的单点实体。相比SVN缺省的开发分支trunk,Git叫做
master,所有修改提交到这个分支上。本工作流只用到master这一个分支。
开发者开始先克隆中央仓库。在自己的项目拷贝中像SVN一样的编辑文件和提交修改;但修改是存在本地的,和中央仓库是
完全隔离的。开发者可以把和上游的同步延后到一个方便时间点。
要发布修改到正式项目中,开发者要把本地master分支的修改『推』到中央仓库中。这相当于svn commit操作,但push操作
会把所有还不在中央仓库的本地提交都推上去。
2.1.2 冲突解决
中央仓库代表了正式项目,所以提交历史应该被尊重且是稳定不变的。如果开发者本地的提交历史和中央仓库有分歧,Git会
拒绝push提交否则会覆盖已经在中央库的正式提交。
在开发者提交自己功能修改到中央库前,需要先fetch在中央库的新增提交,rebase自己提交到中央库提交历史之上。
这样做的意思是在说,『我要把自己的修改加到别人已经完成的修改上。』最终的结果是一个完美的线性历史,就像以前的
SVN的工作流中一样。
如果本地修改和上游提交有冲突,Git会暂停rebase过程,给你手动解决冲突的机会。Git解决合并冲突,用和生成提交一样的
git status和git add命令,很一致方便。还有一点,如果解决冲突时遇到麻烦,Git可以很简单中止整个rebase操作,重来一次
(或者让别人来帮助解决)。
2.1.3 示例
让我们一起逐步分解来看看一个常见的小团队如何用这个工作流来协作的。有两个开发者小明和小红,看他们是如何开发自己
的功能并提交到中央仓库上的。
有人先初始化好中央仓库
第一步,有人在服务器上创建好中央仓库。如果是新项目,你可以初始化一个空仓库;否则你要导入已有的Git或SVN仓库。
中央仓库应该是个裸仓库(bare repository),即没有工作目录(working directory)的仓库。可以用下面的命令创建:
ssh user@host
git init --bare /path/to/repo.git
确保写上有效的user(SSH的用户名),host(服务器的域名或IP地址),/path/to/repo.git(你想存放仓库的位置)。
注意,为了表示是一个裸仓库,按照约定加上.git扩展名到仓库名上。
所有人克隆中央仓库
下一步,各个开发者创建整个项目的本地拷贝。通过git clone命令完成:
git clone ssh://user@host/path/to/repo.git
基于你后续会持续和克隆的仓库做交互的假设,克隆仓库时Git会自动添加远程别名origin指回『父』仓库。
小明开发功能
在小明的本地仓库中,他使用标准的Git过程开发功能:编辑、暂存(Stage)和提交。
如果你不熟悉暂存区(Staging Area),这里说明一下:暂存区的用来准备一个提交,但可以不用把工作目录中所有的修改内
容都包含进来。
这样你可以创建一个高度聚焦的提交,尽管你本地修改很多内容。
git status # 查看本地仓库的修改状态git add # 暂存文件git commit # 提交文件
请记住,因为这些命令生成的是本地提交,小明可以按自己需求反复操作多次,而不用担心中央仓库上有了什么操作。
对需要多个更简单更原子分块的大功能,这个做法是很有用的。
小红开发功能
与此同时,小红在自己的本地仓库中用相同的编辑、暂存和提交过程开发功能。和小明一样,她也不关心中央仓库有没有新提
交;
当然更不关心小明在他的本地仓库中的操作,因为所有本地仓库都是私有的。
小明发布功能
一旦小明完成了他的功能开发,会发布他的本地提交到中央仓库中,这样其它团队成员可以看到他的修改。他可以用下面的
git push命令:
剩余23页未读,继续阅读
资源评论
weixin_38678300
- 粉丝: 4
- 资源: 1002
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 基于景观生态风险评价的流域景观格局优化,教学视频和资料,喜欢的就下载吧,保证受用
- java设计模式-建造者模式(Builder Pattern)
- C语言刷题-lesson5_1731564764305.pdf
- JavaScript开发指南PDG版最新版本
- JavaScript程序员参考(JavaScriptProgrammer'sReference)pdf文字版最新版本
- jQuery1.4参考指南的实例源代码实例代码最新版本
- CUMCM-2018-D.pdf
- jQueryapi技术文档chm含jQuery选择器使用最新版本
- DWIN_SET.rar
- transformer-transformer
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功