使用git、git-flow与gitlab工作
1.摘要
在工作中使用git代替svn也有一段时间了,对于git的一些特性爱不释手的同时也一直遇到相同的问题:“这时候应该打什么命令?”。相对于svn或者vss的简单,git的学习成本还是有些高,如果要使用一个工具还要翻上300页的《Pro Git》,工具的使用成本甚至大于开发本身,这也是我写这篇文章的初衷。
2.安装
下载 git OSX 版
下载 git Windows 版
下载 git Linux 版
Linux下可以直接用apt-get install git或者yum安装。
3.开始使用
注:这篇教程里所有git操作在命令行下执行,windows下可以右键-git bash打开命令行。
如果有人告诉你某某项目的git地址:
git clone username@host:/path/to/repository
或者是你只想自己折腾一下,建立一个空白的版本库:
git init
4.版本控制
4.1.本地版本库
要提交代码到git仓库需要两个命令:
git add
git commit -m “代码提交信息”
要撤销提交:
git reset HEAD
要从从版本库恢复文件:
git checkout —
在git文件夹中实际存在三个区域:
实际目录:实际修改的文件。
待提交区:暂存准备提交的内容,提交之后被清空。(也叫做index区)
已提交区:提交到本地git版本库的内容,有版本号。对这三个区域的操作都可以在本地离线完成。
完整一些的状态图如下:
查看文件状态:
git status
文件总共四种状态:
与git repository一致
与git repository不一致,已缓存
与git repository不一致,未缓存
还未添加到git repository
4.2.远程版本库
从远程更新:
git pull
提交到远程:
git push
远程git与本地git的关系大概是这样:
其中:remotes/origin是git用来管理远程版本库的的隐藏分支,一般不用理会。
5.分支与标记
5.1.分支
分支是用来将特性开发绝缘开来的。在你创建仓库的时候,master 是“默认的”。在其他分支上进行开发,完成后再将它们合并到主分支上。
创建一个叫feature_x的分支,并切换过去:
git branch feature_x
git checkout feature_x
切换回主分支:
git checkout master
再把新建的分支删掉:
git branch -d feature_x
除非你将分支推送到远端仓库,不然该分支就是 不为他人所见的:
git push origin
如果要删除远端仓库里的某个分支:
git push origin :
5.2.合并
要合并其他分支到你的当前分支(例如 master),执行:
git merge
两种情况下,git 都会尝试去自动合并改动。不幸的是,自动合并并非次次都能成功,并可能导致 冲突(conflicts)。 这时候就需要你修改这些文件来人肉合并这些 冲突(conflicts) 了。改完之后,你需要执行如下命令以将它们标记为合并成功:
git add
在合并改动之前,也可以使用如下命令查看:
git diff
5.3.标记
在软件发布时创建标签,是被推荐的。这是个旧有概念,在 SVN 中也有。可以执行如下命令以创建一个叫做 1.0.0 的标签:
git tag 1.0.0
6.工作流与规范化
在工作中,用一个分支来处理开发、测试、发布、线上hotfix等等流程是难以控制的:项目上线前你只想让其他人提交一个小修改,结果fetch下来的是另一个人为下次上线提交上来的几百个文件修改。
这里介绍利用git分支的特性避免这种情况的一种做法:
6.1.永久分支
首先,git远程版本库有两个永久分支,master与develop。
develop分支包含开发过程中最新的提交变更。有人会称之为“集成分支”。该分支是自动化每日构建的代码源。
当develop分支上的源码到达一个稳定的状态时,就可以发布版本。所有develop上的变更都应该以某种方式合并回master分支,并且使用发布版本号打上标签。
每次有变化被合并到master分支时,这就是一次新的产品版本发布。
6.2.临时分支
临时分支是开发或者发布过程中被创建、一段时间后再删掉的分支,同一时间内可能会有多个临时分支在并行工作。
6.2.1.feature
作用:开发新的功能
分支来源:develop
分支结束时合并到:develop
特 性分支(有时也被称作topic分支)是用来为下一发布版本开发新特性。当开始开发一个特性的时候,该特性会成为哪个发布版本的一部分,往往还不知道。特 性分支的重点是,只要特性还在开发,该分支就会一直存在,不过它最终会被合并回develop分支(将该特性加入到发布版本中),或者被丢弃(如果试验的 结果令人失望)。
特性分支往往只存在于开发者的本地仓库中。
6.2.2.release
作用:准备发布新版本
可能的分支来源:develop
分支结束时合并到:develop和master
发布分支为准备新的产品版本发布做支持。它允许你在最后时刻检查所有的细节。此外,它还允许你修复小bug以及准备版本发布的元数据(例如版本号,构建日期等等)。在发布分支做这些事情之后,develop分支就会显得比较干净,也方便为下一大版本发布接受特性。
从 develop分支创建发布分支的时间通常是develop分支(差不多)能反映新版本所期望状态的时候。至少说,这是时候版本发布所计划的特性都已经合 并回了develop分支。而未来其它版本发布计划的特性则不应该合并,它们必须等到当前的版本分支创建好之后才能合并。
正是在发布分支创建的时候,对应的版本发布才获得一个版本号——不能更早。在该时刻之前,develop分支反映的是“下一版本”的相关变更,但不知道这“下一版本”到底会成为0.3还是1.0,直到发布分支被创建。版本号是在发布分支创建时,基于项目版本号规则确定的。
6.2.3.hotfix
作用:修复发行版bug
分支来源:master
分支结束时合并到:develop和master
热 补丁分支和发布分支十分类似,它的目的也是发布一个新的产品版本,尽管是不在计划中的版本发布。当产品版本发现未预期的问题的时候,就需要理解着手处理, 这个时候就要用到热补丁分支。当产品版本的重大bug需要立即解决的时候,我们从对应版本的标签创建出一个热补丁分支。
使用热补丁分支的主要作用是(develop分支上的)团队成员可以继续工作,而另外的人可以在热补丁分支上进行快速的产品bug修复。
6.2.4.流程图
6.3.gitlab与code review
在了解如何review之前先明确几个观点:
1、master分支中的任何版本都认为是可以立即部署的
2、每一次master分支的变更都来自于其它分支向master的合并操作。
3、对master的修改需要review。
借助于gitlab的merge request机制,与上面说的工作流程,我们可以在release分支正式合并到master分支之前建立merge request,在其他人review完成这次合并之后再正式进行合并。
6.3.1.如何review
1、将需要合并到master的分支push到gitlab。
2、进入工程-merge request -create new merge request
3、选择源分支、目标分支,确定。
4、review负责人进入merge request,确认没有问题之后选择Auto Merge(或者手动在本地合并之后再push到gitlab),并关闭这个merge request,完成。
5、如果发现问题那么在有问题的行下注释,并提醒request的发起人及时修改。
6.4.git flow
git flow是git的辅助工具,实质上是一些分支-合并的脚本集合,使用git flow可以更轻松的完成对各种特性分支的操作。
安装:
apt-get install git-flow
将git库转换为git-flow库:
git flow init
实质上这一步只是为git flow中的几个特性分支命名。
开始一个新功能:
git flow feature start xxxx
提交这个功能到远程库:
git flow feature publish xxxx
完成功能,合并到develop:
git flow feature finish xxxx
记得删除远程仓库里的分支:
git push origin :xxxx
release,hotfix与之类似,唯一的一点区别:hotfix目前没有publish功能,所以提交远程仓库的这一步要改成:
git push origin hotfix/xxxx:hotfix/xxxx
注意:
git flow只是在本地执行分支/合并操作的脚本,不是一个流程管理工具。
7.更进一步
几个常用命令:
git reset
A). –hard:重设(reset) index和working directory,自从
B). –soft:index和working directory中的内容不作任何改变,仅仅把HEAD指向
C). –mixed:仅reset index,但是不reset working directory。这个模式是默认模式,即当不显示告知git reset模式时,会使用mixed模式。
**git checkout **
-b 签出并创建分支
-t 签出并追踪远程分支
**git rebase **
合并/修改提交
git remote -av
显示所有远程仓库
git push -u
设置分支对应的远程仓库
8.参考资料
![知识共享许可协议](https://i.creativecommons.org/l/by-nc/4.0/80x15.png)
本作品采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可,转载请注明作者及原网址。
值得入门学习。
gitlab哪个环境搭建文档超级麻烦
回复@RedShoes:我没有那些东西能炫啊
人家微博炫富炫妹子,你怎么不能主流一点呢
回复@Aboboda:你全家都是学霸
学霸你好