Git工作流指南:集中式工作流
转到分布式版本控制系统看起来像个令人生畏的任务,但不改变已用的工作流你也可以用上Git
带来的收益。团队可以用和Subversion
完全不变的方式来开发项目。
但使用Git
加强开发的工作流,Git
比SVN有
几个优势。首先,每个开发可以有属于自己的整个工程的本地拷贝。隔离的环境让各个开发者的工作和项目的其他部分(修改)独立开来 —— 即自由地提交到自己的本地仓库,先完全忽略上游的开发,直到方便的时候再把修改反馈上去。
其次,Git
提供了强壮的分支和合并模型。不像SVN
,Git
的分支设计成可以做为一种用来在仓库之间集成代码和分享修改的『失败安全』的机制。
工作方式
像Subversion
一样,集中式工作流以中央仓库作为项目所有修改的单点实体。相比SVN
缺省的开发分支trunk
,Git
叫做master
,所有修改提交到这个分支上。该工作流只用到master
这一个分支。
开发者开始先克隆中央仓库。在自己的项目拷贝中,像SVN
一样的编辑文件和提交修改;但修改是存在本地的,和中央仓库是完全隔离的。开发者可以把和上游的同步延后到一个方便时间点。
要发布修改到正式项目中,开发者要把本地master
分支的修改『推(push)』到中央仓库中。这相当于svn commit
操作,但push
操作会把所有还不在中央仓库的本地提交都推上去。
冲突解决
中央仓库代表了正式项目,所以提交历史应该被尊重且是稳定不变的。如果开发者本地的提交历史和中央仓库有分歧,Git
会拒绝push
提交否则会覆盖已经在中央库的正式提交。
在开发者提交自己功能修改到中央库前,需要先fetch
在中央库的新增提交,rebase
自己提交到中央库提交历史之上。这样做的意思是在说,『我要把自己的修改加到别人已经完成的修改上。』最终的结果是一个完美的线性历史,就像以前的SVN
的工作流中一样。
如果本地修改和上游提交有冲突,Git
会暂停rebase
过程,给你手动解决冲突的机会。Git
解决合并冲突,用和生成提交一样的git status
和git add
命令,很一致方便。还有一点,如果解决冲突时遇到麻烦,Git
可以很简单中止整个rebase
操作,重来一次(或者让别人来帮助解决)。
示例
让我们一起逐步分解来看看一个常见的小团队如何用这个工作流来协作的。有两个开发者小明和小红,看他们是如何开发自己的功能并提交到中央仓库上的。
有人先初始化好中央仓库
第一步,有人在服务器上创建好中央仓库。如果是新项目,你可以初始化一个空仓库;否则你要导入已有的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
命令:
git push origin master
注意,origin
是在小明克隆仓库时Git
创建的远程中央仓库别名。master
参数告诉Git
推送的分支。由于中央仓库自从小明克隆以来还没有被更新过,所以push
操作不会有冲突,成功完成。
小红试着发布功能
一起来看看在小明发布修改后,小红push
修改会怎么样?她使用完全一样的push
命令:
git push origin master
但她的本地历史已经和中央仓库有分岐了,Git
拒绝操作并给出下面很长的出错消息:
error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
这避免了小红覆写正式的提交。她要先pull
小明的更新到她的本地仓库合并上她的本地修改后,再重试。
小红在小明的提交之上rebase
小红用git pull
合并上游的修改到自己的仓库中。这条命令类似svn update
——拉取所有上游提交命令到小红的本地仓库,并尝试和她的本地修改合并:
git pull --rebase origin master
--rebase
选项告诉Git
把小红的提交移到同步了中央仓库修改后的master
分支的顶部,如下图所示:
如果你忘加了这个选项,pull
操作仍然可以完成,但每次pull
操作要同步中央仓库中别人修改时,提交历史会以一个多余的『合并提交』结尾。对于集中式工作流,最好是使用rebase
而不是生成一个合并提交。
小红解决合并冲突
rebase
操作过程是把本地提交一次一个地迁移到更新了的中央仓库master
分支之上。这意味着可能要解决在迁移某个提交时出现的合并冲突,而不是解决包含了所有提交的大型合并时所出现的冲突。这样的方式让你尽可能保持每个提交的聚焦和项目历史的整洁。反过来,简化了哪里引入Bug
的分析,如果有必要,回滚修改也可以做到对项目影响最小。
如果小红和小明的功能是相关的,不大可能在rebase
过程中有冲突。如果有,Git
在合并有冲突的提交处暂停rebase
过程,输出下面的信息并带上相关的指令:
CONFLICT (content): Merge conflict in
Git
很赞的一点是,任何人可以解决他自己的冲突。在这个例子中,小红可以简单的运行git status
命令来查看哪里有问题。冲突文件列在Unmerged paths
(未合并路径)一节中:
1
2
3
4
5
|
# Unmerged paths:
# (use "git reset HEAD <some-file>..." to unstage)
# (use "git add/rm <some-file>..." as appropriate to mark resolution)
#
# both modified: <some-file>
|
接着小红编辑这些文件。修改完成后,用老套路暂存这些文件,并让git rebase
完成剩下的事:
git add
git rebase --continue
要做的就这些了。Git
会继续一个一个地合并后面的提交,如其它的提交有冲突就重复这个过程。
如果你碰到了冲突,但发现搞不定,不要惊慌。只要执行下面这条命令,就可以回到你执行git pull --rebase
命令前的样子:
git rebase --abort
小红成功发布功能
小红完成和中央仓库的同步后,就能成功发布她的修改了:
git push origin master
下一站
如你所见,仅使用几个Git
命令我们就可以模拟出传统Subversion
开发环境。对于要从SVN
迁移过来的团队来说这太好了,但没有发挥出Git
分布式本质的优势。
如果你的团队适应了集中式工作流,但想要更流畅的协作效果,绝对值得探索一下功能分支工作流的收益。通过为一个功能分配一个专门的分支,能够做到一个新增功能集成到正式项目之前对新功能进行深入讨论。
本文由 伯乐在线 - 李鼎 翻译。 源文地址:http://blog.jobbole.com/76847/
英文出处:atlassian。
转载于:https://www.cnblogs.com/jiuyi/p/7688281.html
Git工作流指南:集中式工作流相关推荐
- Git学习笔记(集中式版本控制工具与分布式版本控制工具)
集中式版本控制工具 集中式版本控制工具是指所有的项目版本都存储在唯一的服务器中,而团队中使用者本地只保存有最新版本.因此,当服务器宕机或故障时,服务器中文件如果损坏或缺失,使用者本地只有最新版本,因此 ...
- 【git】—集中式与分布式版本控制系统
[前言] 大家都知道,Linus在1991年创建了开源的Linux,从此,Linux系统不断发展,已经成为最大的服务器系统软件了,之前的linux代码是由Linus本人通过手工方式合并代码,后来为了切 ...
- Git三大特色之WorkFlow(工作流)
开篇 Git 三大特色,分支,暂存区,工作流,今天终于要写到 WorkFlow 了,我彷佛已经看到胜利的曙光,走起. 何谓工作流 WorkFlow 的字面意思,工作流,即工作流程.在分支篇里,有说过这 ...
- 《CCNA无线640-722认证考试指南》——9.3节集中式架构
本节书摘来自异步社区<CCNA无线640-722认证考试指南>一书中的第9章,第9.3节集中式架构,作者 [美]David Hucaby,更多章节内容可以访问云栖社区"异步社区& ...
- Git复习(一)之简介、安装、集中式和分布式
简介 Git是分布式版本控制系统,使用C语言开发的,CVS.SVN是集中式的版本控制系统,集中式的版本控制系统不但速度慢,而且必须联网才能使用. Git是分布式版本控制系统,同一个Git仓库,可以 分 ...
- 版本控制:集中式(SVN) vs 分布式(GIT)
Linus一直痛恨的CVS及SVN都是集中式的版本控制系统,而Git是分布式版本控制系统,集中式和分布式版本控制系统有什么区别呢? 先说集中式版本控制系统,版本库是集中存放在中央服务器的,而干活的时候 ...
- 解读Git与SVN的区别(集中式VS分布式)
Git是目前世界上最先进的分布式版本控制系统,其实 Git 跟 SVN一样有自己的集中式版本库或服务器,但是Git 更倾向于被使用于分布式模式,也就是每个开发人员从中心版本库/服务器上chect ou ...
- git 集中式vs分布式
转自http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001374027586935 ...
- Git集中式vs分布式笔记
git简介 是目前世界上先进的分布式版本控制系统(没有之⼀). 不但能自动帮我记录每次文件的改动,还可以让同事协作编辑,这样就不用自己管理一堆类似的文件了,也不需要把文件传来传去.Linus花了两周时 ...
最新文章
- 什么是“可证伪性”?
- 支付宝APP支付 统一下单 php服务端 tp5
- Apollo进阶课程⑲丨Apollo感知之旅——感知算法
- WCF trace、log
- 傻瓜式操作的三个网络赚零花钱的小项目
- 【天梯选拔月赛】寻宝路线(dp)
- matlab m 调用mdl,[分享]MATLAB m语言中调用simulink的程序
- 计算机键盘卡扣原理,笔记本键盘怎么拆?笔记本键盘卡扣、排线如何打开?
- 微信分享自定义图标大小限制_微信分享时安卓的自定义参数无效的解决办法
- 一篇文章带你了解和学会VCN安卓快速开发
- Jenkins 凭据密码忘记获取凭据密码
- 精简指令集的特点_精简指令集有哪些指令
- git中的配置文件(/etc/gitconfig,${HOME}/.gitconfig,.git/config)
- Android 12.0 第三方app安装完成后默认授予运行时权限
- 净利润同比增长54%,阿里巴巴下沉市场称王?
- 从零开始搭建一个属于自己的网站
- FIFO的工作原理及其设计
- Blender渲染课程学习笔记
- 中国智慧农业发展研究报告 附下载
- 转转,敦刻尔克大撤退?
热门文章
- ABAP,Java, nodejs和go语言的web server编程
- java+mysql性能优化_Java培训实战教程之mysql优化
- 计算机如何去除桌面名称阴影,电脑桌面图标有阴影怎么去掉 电脑桌面图标阴影去掉方法【图文】...
- 剑指offer刷题(java)|二维数组中的查找|替换空格|leetcode刷题
- 证明kruskal算法求解图的最小生成树具有贪心选择性质_将并查集应用在图论中的最小生成树算法——Kruskal...
- eclipse git提交代码_来看看大厂的Git提交规范,千万别乱提交代码哦...
- 插入区间Python解法
- 计算机管理与维护实践课程,天津2012年自考“计算机维护维修(实践)”课程考试大纲...
- Linux解决 -bash: nc: command not found问题,安装nc
- JAVA复习5(集合——HashSet)