GIT--使用流程规范

time 20200216

author Venki

company GolddengLighting

目录指引

适用对象
背景介绍
svn介绍
Git介绍
Github介绍
Gitlab介绍
Gitflow介绍
svn与git
github与gitlab
实战演练
参考文献

适用对象
回到顶部

开发人员

前端工程师
后端工程师
测试工程师

运维人员

服务器运维工程师
桌面运维工程师

产品运营人员

产品经理
运营专员

背景介绍
回到顶部

什么是版本控制

你可以把一个版本控制系统（缩写VCS）理解为一个“数据库”，在需要的时候，它可以帮你完整地保存一个项目的快照。当你需要查看一个之前的快照（称之为“版本”）时，版本控制系统可以显示出当前版本与上一个版本之间的所有改动的细节。

为什么需要版本控制系统

未使用带来的问题

当你需要处理那些共享文件夹中的文件时，你必须告知办公室里的所有人，你正在对哪些文件进行编辑；与此同时，其他人必须要避免与操作相同的文件。这是一个不现实和完全错误的流程。当你花了很长时间完成你的编辑后，可能这些文件早已经被团队里的其他开发成员修改或者删除了。
你到底改动了什么？仅仅是针对一些特定文件的改动还是整个项目？首先你必须及时并小心地审查整个项目的每一个可能的改动细节，然后你需要付出大量且并不必要的时间来整理它。
你如何命名这些版本？如果你是一个思维很有条理的人，你也许会定义一个比较容易理解的通用命名规则（比如这样 “acme-inc-redesign-2013-11-12-v23”）。然而一旦涉及到一个多样性的改变（比如：在一次版本改动中，一些改动了标题区而另一些却没有被改动它），仅仅通过名字是很难追踪和判断这些改动的。
最重要的问题可能就是你如何知道在第一个版本和第二个版本之间到底进行了哪些改动？只有很少人会真正地去花时间来仔细记录和观察每一个重要的变化，例如在项目文件夹的每一个README文件。

使用后

每一个团队成员都可以在任何时间对任何文件毫无顾虑的进行修改，版本控制系统可以把之后所有的改动合并成一个共同的版本，不论是一个文件还是整个项目。这个共同的中心平台就是我们的版本控制系统。
每一个版本控制系统仅仅对应一个项目。因此，在你的本地只存在一个版本，那就是这个项目的当前工作版本。除此之外，而其它所有之前的版本和改动都已经被有序地存储在版本控制系统中了。当你需要时，你可以随时来查看之前的任何一个版本，而且还可以得到整个项目的快照。
要把一些文件恢复到上次改动之前的版本（甚至整个项目恢复到之前的版本）。这可能意味着你发现了一些严重的问题！如果你确定那些改动是错误的或者是没有必要的，那轻松的点几下你就可以简单地撤销它。在项目的每一个重要阶段，认识和正确地使用撤销这个功能会让你的工作变得非常轻松。
每当你提交一次对项目新的改动时，你的版本管理系统会要求你添加一个对这次改动的简短描述。除此之外（如果是一个代码或者文本文件），你还可以看到一个改动前和改动后的内容的详细对照。这样也可以帮助你很好地了解版本与版本之间的发展关系。
备份是一个分布式版本控制系统（例如 Git）提供的非常好的附带功能。每一个团队成员都会在他的本地有一个完整的项目副本，包括整个项目的历史记录。如果你所依赖的服务器宕机了，或者是你的存储硬盘坏，所有你需要的恢复文件都可以在另外的团队成员的 Git 本地仓库中得到。

svn介绍
回到顶部

svn简介

Apache Subversion 通常被缩写成 SVN，是一个开放源代码的版本控制系统，Subversion 在 2000 年由 CollabNet Inc 开发，现在发展成为 Apache 软件基金会的一个项目，同样是一个丰富的开发者和用户社区的一部分。SVN相对于的RCS、CVS，采用了分支管理系统，它的设计目标就是取代CVS。互联网上免费的版本控制服务多基于Subversion。
Subversion(SVN) 是一个开源的版本控制系統, 也就是说 Subversion 管理着随时间改变的数据。这些数据放置在一个中央资料档案库(repository) 中。这个档案库很像一个普通的文件服务器, 不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本, 或是浏览文件的变动历史。

svn优点

原子提交。一次提交不管是单个还是多个文件，都是作为一个整体提交的。在这当中发生的意外例如传输中断，不会引起数据库的不完整和数据损坏。
重命名、复制、删除文件等动作都保存在版本历史记录当中。
对于二进制文件，使用了节省空间的保存方法。（简单的理解，就是只保存和上一版本不同之处）
目录也有版本历史。整个目录树可以被移动或者复制，操作很简单，而且能够保留全部版本记录。
分支的开销非常小。
优化过的数据库访问，使得一些操作不必访问数据库就可以做到。这样减少了很多不必要的和数据库主机之间的网络流量。

svn工作流程

SVN是一个增量式的版本控制，它不会讲各个版本的副本都完整的保存下来，而只会记录下版本之间的差异，然后按照顺序更新或者恢复特定版本的数据。这使得服务端的存储量会非常低。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-m51zB4Jm-1615276631174)(http://q214kfijz.bkt.clouddn.com/svn%E5%8E%9F%E7%90%86%E5%9B%BE.jpg)]

Git介绍
回到顶部

git简介

很多人都知道，Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。

不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。安定团结的大好局面在2005年就被打破了，原因是Linux社区牛人聚集，不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个），被BitMover公司发现了（监控工作做得不错！），于是BitMover公司怒了，要收回Linux社区的免费使用权。

Linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。实际情况是这样的：Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？大家可以体会一下。

Linus一直痛恨的CVS及SVN都是集中式的版本控制系统，而Git是分布式版本控制系统，集中式和分布式版本控制系统有什么区别呢？

先说集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。
集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟，这还不得把人给憋死啊。
那分布式版本控制系统与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。
和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。
在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ULODjdUs-1615276631176)(http://q214kfijz.bkt.clouddn.com/svn%E5%8E%9F%E7%90%86%E5%9B%BE1.jpg)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ICeEyiq6-1615276631177)(http://q214kfijz.bkt.clouddn.com/git%E6%B5%81%E7%A8%8B%E5%9B%BE.jpg)]

git工作流程

一般工作流程如下：

克隆 Git 资源作为工作目录
在克隆的资源上添加或修改文件
如果其他人修改了，你可以更新资源
在提交前查看修改
提交修改
在修改完成后，如果发现错误，可以撤回提交并再次修改并提交

原理图
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-otmf4ZUS-1615276631179)(http://q214kfijz.bkt.clouddn.com/git-process.png)]

git优缺点

优点
- 适合分布式开发，强调个体
- 公共服务器压力和数据量都不会太大
- 速度快、灵活
- 任意两个开发者之间可以很容易的解决冲突
- 离线工作
缺点
- 资料少（起码中文资料很少）
- 学习周期相对而言比较长
- 不符合常规思维
- 代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息

Github介绍
回到顶部

Github简介

git是版本控制系统，而github是在线的基于git的代码托管服务。百度百科说github是一个面向开源及私有软件项目的托管平台，因为仅仅支持git作为唯一的版本库格式进行托管，因此成为github。托管可以分为共有托管和私有托管，及不收费项目和收费项目。github可以托管各种git库，并且提供一个web界面。它的一个特殊的卖点就是从另外一个项目进行分支很简单。目前该平台已经被微软收购。

Github工作流程

将按照gitflow进行

Github优缺点

优势：
- 完整的支持Markdown语言，而且支持Emoji表情
- 支持直接复制图片到页面，会自动上传图片(非常好的功能，知乎也支持)
- 比较好的支持Mobile。虽然github没有手机客户端，但是一般开发者，写好的blog都会通过微博进行分享，所以点击过来之后，就可以在手机浏览器里面访问
- 使用github原生的功能，就可以进行类似评论的功能
- 支持@用户功能
- 支持标签，当然是你repository里面
- 强调个人，符合hacker更看重名誉/成就感的天性
- 功能设计简洁实用上手很快，可用性好，已有很多相当质量的各类项目和优秀开发者在上面。
劣势：
- （对个人而言）
  - GitHub 使用 git 分布式版本控制系统，而 git 最初是 Linus Torvalds 为帮助Linux开发而创造的，它针对的是 Linux 平台，git 和 Windows 从来不是最好的朋友，因为它一点也不像 Windows。GitHub 发布了GitHub for Windows，为 Windows 平台开发者提供了一个易于使用的 Git 图形客户端。
  - 国内访问速度太慢，经常出现connect time-out
  - 不能很好的解决GB2312/GBK，对中文不够友好
  - wiki功能太弱，直接导致文档（对于开源项目很重要）经常被分离到一个独立站点
- （对企业而言）
  - 免费套餐不支持私有项目，无非解决企业内部的需求，github:fi价格过高（最便宜要$5,000/年）
  - 基于git，学习曲线陡峭，企业大规模用git根本不现实。尤其国内大家都刚学会svn
  - github有时可能被墙，或者不稳定
  - 没有集成社交分享功能。比如后面可以分享到微博，微信朋友圈等。之前有人建议我去做插件，有时间看看这个。（据说是这样我还没有考证）

Gitlab介绍
回到顶部

Gitlab简介

git是版本控制系统（分布式），github是在线的基于git的代码托管服务，提供公共（免费）托管和私有（收费）托管。相对于大部分国人来说，一直比较喜欢免费的。而gitlab就解决了这个问题。在gitlab上，个人开免费创建私有的repo（仓库）。gitlab也是基于git的代码托管服务。只是因为gitlab解决了创建私有repo收费的问题。另外使用gitlab，需要自己搭建一个服务器，而github可以直接注册使用。

Gitlab工作流程

将按照gitflow进行

Gitlab优缺点

优点
- GitLab拥有GitHub拥有的一切，但他拥有更多——让团队对它们的repositories拥有更多的控制
- 非常便捷的用户界面，在同一界面上获取到：projects，最近的projects，用户，最近的用户，群组和状态
- 允许设置仓库权限是公用的还是私有的
- “Snippet support”让用户分享一个project的部分代码，而不是整个project
- 受保护的分支是一种提升代码安全性的新方法，它们允许用户设置project的获取权限，所以一个团队中只有特定的人可以push，force push或者删除一个分支的代码
- Authentication levels更进一步的提升安全性，允许用户给人读写以外的权限。举例来说，你可以给一个组员跟踪变动的权限却不给他获取代码的权限
- 你可以设置获取到团队的整体的改进进度，而不是你个人的进度
- 开发者通过打上“仍在进行中”状态标签让其他成员知道代码没有完成，从而阻止未完成的代码合并到其他的代码中
- “innersourcing”公司的资源如果员工不再权限范围内，将不知道这个资源的存在
- GitLab更适合企业级使用
缺点

Gitflow介绍
回到顶部

简介

Git Flow定义了一个项目发布的分支模型，为管理具有预定发布周期的大型项目提供了一个健壮的框架。就像代码需要代码规范一样，代码管理同样需要一个清晰的流程和规范

流程解析

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FE32xNYr-1615276631180)(http://q214kfijz.bkt.clouddn.com/gitflow.png)]

GitFlow的常用分支

master

主分支 , 产品的功能全部实现后 , 最终在master分支对外发布
该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 , 不能在此分支修改
另外所有在master分支的推送应该打标签做记录,方便追溯
例如release合并到master , 或hotfix合并到master

develop

主开发分支 , 基于master分支克隆
包含所有要发布到下一个release的代码
该分支为只读唯一分支 , 只能从其他分支合并
feature功能分支完成 , 合并到develop(不推送)
develop拉取release分支 , 提测
release/hotfix 分支上线完毕 , 合并到develop并推送

feature

功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发
功能开发完毕后合到develop分支(未正式上线之前不推送到远程中央仓库!!!)
feature分支可同时存在多个 , 用于团队中多个功能同时开发 , 属于临时分支 , 功能完成后可选删除

release

测试分支 , 基于feature分支合并到develop之后, 从develop分支克隆
主要用于提交给测试人员进行功能测试 , 测试过程中发现的BUG在本分支进行修复 , 修复完成上线后合并到develop/master分支并推送(完成功能) , 打Tag
属于临时分支 , 功能上线后可选删除

hotfix

补丁分支 , 基于master分支克隆 , 主要用于对线上的版本进行BUG修复
修复完毕后合并到develop/master分支并推送 , 打Tag
属于临时分支 , 补丁修复上线后可选删除
所有hotfix分支的修改会进入到下一个release

主要工作流程

初始化项目为gitflow , 默认创建master分支 , 然后从master拉取第一个develop分支
从develop拉取feature分支进行编码开发(多个开发人员拉取多个feature同时进行并行开发 , 互不影响)
feature分支完成后 , 合并到develop(不推送 , feature功能完成还未提测 , 推送后会影响其他功能分支的开发)合并feature到develop , 可以选择删除当前feature , 也可以不删除 . 但当前feature就不可更改了 , 必须从release分支继续编码修改
从develop拉取release分支进行提测 , 提测过程中在release分支上修改BUG
release分支上线后 , 合并release分支到develop/master并推送合并之后 , 可选删除当前release分支 , 若不删除 , 则当前release不可修改 . 线上有问题也必须从master拉取hotfix分支进行修改
上线之后若发现线上BUG , 从master拉取hotfix进行BUG修改
hotfix通过测试上线后 , 合并hotfix分支到develop/master并推送合并之后 , 可选删除当前hostfix , 若不删除 , 则当前hotfix不可修改 , 若补丁未修复 , 需要从master拉取新的hotfix继续修改
当进行一个feature时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上即合并develop到当前feature分支
当进行一个release分支时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上即合并develop到当前release分支 (!!! 因为当前release分支通过测试后会发布到线上 , 如果不合并最新的develop分支 , 就会发生丢代码的情况)

svn与git
回到顶部

最核心的区别Git是分布式的，而Svn不是分布的。话说回来Git跟Svn一样有自己的集中式版本库和Server端，但Git更倾向于分布式开发，因为每一个开发人员的电脑上都有一个Local Repository,所以即使没有网络也一样可以Commit，查看历史版本记录，创建项目分支等操作，等网络再次连接上Push到Server端
Git把内容按元数据方式存储，而SVN是按文件：因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。.git目录的体积大小跟.svn比较，你会发现它们差距很大
Git没有一个全局版本号，而SVN有：目前为止这是跟SVN相比Git缺少的最大的一个特征
Git的内容的完整性要优于SVN: GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏
Git下载下来后，在OffLine状态下可以看到所有的Log,SVN不可以
SVN必须先Update才能Commit,忘记了合并时就会出现一些错误，git还是比较少的出现这种情况。
克隆一份全新的目录以同样拥有五个分支来说，SVN是同时复製5个版本的文件,也就是说重复五次同样的动作。而Git只是获取文件的每个版本的元素，然后只载入主要的分支(master)在我的经验,克隆一个拥有将近一万个提交(commit),五个分支,每个分支有大约1500个文件的 SVN,耗了将近一个小时！而Git只用了区区的1分钟
版本库（repository):SVN只能有一个指定中央版本库。当这个中央版本库有问题时，所有工作成员都一起瘫痪直到版本库维修完毕或者新的版本库设立完成。而Git可以有无个版本库。或者，更正确的说法，每一个Git都是一个版本库，区别是它们是否拥有活跃目录（GitWorkingTree）。如果主要版本库（例如：置於GitHub的版本库）发生了什麼事工作成员仍然可以在自己的本地版本库（local repository）提交，等待主要版本库恢复即可。工作成员也可以提交到其他的版本库
分支（Branch）在SVN，分支是一个完整的目录。且这个目录拥有完整的实际文件。如果工作成员想要开啟新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。如果你的分支是用来进行破坏工作（安检测试），那将会像传染病一样,你改一个分支，还得让其他人重新切分支重新下载，十分狗血。而Git，每个工作成员可以任意在自己的本地版本库开啟无限个分支。举例：当我想尝试破坏自己的程序（安检测试），并且想保留这些被修改的文件供日后使用，我可以开一个分支，做我喜欢的事。完全不需担心妨碍其他工作成员。只要我不合并及提交到主要版本库，没有一个工作成员会被影响。等到我不需要这个分支时，我只要把它从我的本地版本库删除即可。无痛无痒
Git的分支名是可以使用不同名字的。例如：我的本地分支名为OK，而在主要版本库的名字其实是master最值得一提，我可以在Git的任意一个提交点（commit point）开启分支！（其中一个方法是使用gitk –all 可观察整个提交记录，然后在任意点开啟分支。）
提交（Commit）在SVN，当你提交你的完成品时，它将直接记录到中央版本库。当你发现你的完成品存在严重问题时，你已经无法阻止事情的发生了。如果网路中断，你根本没办法提交！而Git的提交完全属於本地版本库的活动。而你只需“推”（git push）到主要版本库即可。Git的“推”其实是在执行“同步”（Sync）。

github与gitlab
回到顶部

两者区别：

相同点：二者都是基于web的Git仓库，在很大程度上GitLab是仿造GitHub来做的，他们都提供了分享开源项目的平台，为开发团队提供了存储、分享、发布和合作开发项目的中心化云存储的场所。
不同点：
- GitHub如果使用私有仓库，是需要付费的，GitLab可以在上面搭建私人的免费仓库
- GitLab让开发团队对他们的代码仓库拥有更多的控制，相对于GitHub，它有不少的特色
  - 允许免费设置仓库权限
  - 允许用户选择分享一个project的部分代码
  - 允许用户设置project的获取权限，进一步提升安全性
  - 可以设置获取到团队整体的改进进度
  - 通过innersourcing让不在权限范围内的人访问不到该资源

实战演练
回到顶部

gitflow工作流程

创建develop分支

git branch develop
git push -u origin develop

开始新Feature开发

git checkout -b some-feature develop
# Optionally, push branch to origin:
git push -u origin some-feature

# 做一些改动    
git status
git add some-file
git commit

完成Feature

git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop

git branch -d some-feature

# If you pushed branch to origin:
git push origin --delete some-feature

开始Relase

git checkout -b release-0.1.0 develop

# Optional: Bump version number, commit
# Prepare release, commit

完成Release

git checkout master
git merge --no-ff release-0.1.0
git push

git checkout develop
git merge --no-ff release-0.1.0
git push

git branch -d release-0.1.0

# If you pushed branch to origin:
git push origin --delete release-0.1.0   


git tag -a v0.1.0 master
git push --tags

开始Hotfix

git checkout -b hotfix-0.1.1 master

完成Hotfix

git checkout master
git merge --no-ff hotfix-0.1.1
git push

git checkout develop
git merge --no-ff hotfix-0.1.1
git push

git branch -d hotfix-0.1.1

git tag -a v0.1.1 master
git push --tags

gitflow工具