Git代码管理艺术之基本介绍

Git代码管理艺术之基本介绍

大纲

1版本控制系统

2Git简介

3Git基础 4Git操作 5Git版本管理

6GIT分支管理在项目中的实践

版本控制系统

VCS - Version Control System

"版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。"

• 记录文件的所有历史变化
• 随时可恢复到任何一个历史状态
• 多人协作开发或修改
• 错误恢复
• 多功能的并行开发

版本控制系统或工具的发展史

版本控制系统分类

• 本地版本控制系统 (Local VCS)
• 集中式版本控制系统 (Centralized VCS)：CVS,Firefly,TFS
• 分布式版本控制系统 (Distributed VCS):GIT

Git 简史

2002 年，linux项目组开始启用分布式版本控制系统 BitKeeper 来管理和维护代码。

2005 年的时候，开发 BitKeeper 的商业公司同 Linux

内核开源社区的合作关系结束，他们收回了免费使用BitKeeper 的权力

April 5, 2005 – Linus发布首个git版本

June 15, 2005 - Git 用作Linux源码版本控制

Git创建时的目标

1. 速度

2. 简单的设计 3. 对非线性开发模式的强力支持（允许上千个并行开发的分支） 4. 完全分布式 5. 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

Git简介

u git是一个快速，开源，分布式的版本控制系统，在开源和协作编程社区很快取代了svn。

Ø可以利用它来追踪项目中的文件

Ø可以和合作伙伴共享版本历史状态

Ø可以将合作伙伴的工作和你的工作进行合并

Ø可以对整个工程或某些文件跟历史版本进行比较或者恢复到早期的某个版本。

Git简介

它的特点在于：

Ø 1.开源 Ø 2.高速

Ø 3.节省大量空间

Ø 4.灵活、简洁、高效的分支管理

它能最大限度地发挥多人协同并发编程的效能，让分支管理更快速，版本管理更简单

GIT简介-开源

• GIT源码地址：git-scm.com/download

• GIT许可证：GNU通用公共许可证（GNU

General Public License）

大纲

Git简介 Git基础 Git操作

Git版本管理

GIT分支管理在项目中的实践

离线

Git是完全的分布式处理，它可以离线工作。

跟SVN完全不同，Git的所有操作几乎不需要网络连接，包括历史回顾，差异显示和提交

快速

Git比其他的VCS工具要快很多，因为git绝大部分是离线操作，对网络依赖小

• time git clone ssh://gufeiyong@scm.hz.netease.com:2222/backend/datastream.git >/dev/null real0m26.559s user0m2.568s sys0m1.028s
• time svn co https://svn.hz.netease.com/svn/datastream >/dev/null real3m14.684s user1m1.156s sys0m20.897s

占用空间小

git比较节省空间。Django项目为例。

44M ./django-git 53M ./django-svn

git克隆比SVN要小很多，且git克隆包含整个项目的历史版本。

SVN只包含项目的最后一个版本。

快照

git是基于快照的，而不是补丁文件包含一些元数据（提交信息（message），作

者，日期等等），一个commit指向这次提交时项目的快照。

分支

以前的VCS工具分支的方法是对每一个分枝都放到一个独立的目录中。而git可以让你在同一个工作目录中切换（switch）到不同的分枝。

创建和切换分枝几乎是即时的（instant），并且存在本地分支

git开发者可以随时创建，合并，删除多个分枝。它鼓励一种非线性的开发周期，它可以说是并行的多线程模式而不是多个步骤串行的模式。

集中化的版本控制系统

坏处：好处：每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限。

Ø（1）中央服务器的单点故障，无法提交更新，也就无法协同工作。

Ø（2）要是中央服务器的磁盘发生故障，碰巧没做备份，会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录

分布式版本控制系统

像GIT这种系统，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。

大纲

Git简介 Git基础 Git操作

Git版本管理

GIT分支管理在项目中的实践

创建仓库

Git init 创建一个空仓库

git clone git://github.com/schacon/grit.git mygrit

复制一个远程仓库到本地

常用文件操作命令

git status 查看文件状态 git add <file> 跟踪新文件或暂存已修改文件 git diff 查看文件变化 git commit –m <msg> 提交更新 git rm file 移除文件 git log 查看提交日志

git commit –ammend 修改最后一次提交 git reset HEAD <file> 取消已暂存文件 git checkout -- <file> 取消文件修改

远程仓库操作

git clone <仓库地址> git remote –v 列出所有远程仓库 git push <仓库名> <分支名> 推送本地分支更新到远程仓库 git fetch 从远程仓库获取更新 git pull从远程仓库获取更新并merge本地分支

大纲

Git简介 Git基础 Git操作

GIT版本管理

GIT分支管理在项目中的实践

GIT的文件流转区域

Git 管理项目时，文件流转的三个工作区域：Git 的工作目录，暂存区域，以及本地仓库。

GIT版本

Git版本号是一个40位的SHA-1编码的字符串例如：

4dd6bd612a121b24e1877dbc632e422e305 dde6c

它不像svn那样版本号是连续的，很容易从版本号看出哪个是新版本，git的版本号是不连续的

查看历史版本

可以通过git log 命令来查看历史版本的提交 git log的操作都是本地操作，基本都能瞬间完成，比SVN快很多，查看历史版本或进行diff 比较都非常方便也可以通过git revert操作来回退到历史版本

查看祖先引用

git log --pretty=format:'%h %s' --graph

git log

$ git log

commit 734713bc047d87bf7eac9674765ae793478c50d3

Author: Scott Chacon <schacon@gmail.com> Date: Fri Jan 2 18:32:33 2009 -0800 fixed refs handling, added gc auto, updated tests commit d921970aadf03b3cf0e71becdaab3147ba71cdef Merge: 1c002dd... 35cfb2b...

Author: Scott Chacon <schacon@gmail.com>

SHA-1

SHA-1 摘要长度是20 字节

如果地球上65 亿的人类都在编程，每人每秒都在产生等价于整个Linux 内核历史

（一百万个Git 对象）的代码，并将之提交到一个巨大的Git 仓库里面，那将花费5 年的时间才会产生足够的对象，使其拥有50% 的概率产生一次SHA-1 对象冲突。

查看提交范围

git log master..experiemnt

D

C

查看提交范围

git log origin/master..HEAD

这条命令显示任何在你当前分支上而不在远程 origin 上的提交。如果你运行git push 并且的你的当前分支正在跟踪origin/master，

被git log origin/master..HEAD

储藏

一个很实用的功能在git切换分支的时候，他会提示你有未提交的更新，你需要commit才能切换，但可能当前代码很乱不能提交

git stash - 将未提交代码储藏

git stash apply- 取出储藏的代码

变更历史

git允许你修改提交历史，这个很有用，可以减少那些乱七八糟的提交弄乱git仓库

git commit -ammend

这会更改Sha-1值，不能再push之后再修改

git调试

Git有个挺有用的功能，可以找出你觉得有问题的代码在哪个版本引入的

git blame -L 32,36 xxx.java

子模块

第三方开发的库或者是你独立开发和并在多个父项目中使用的项目作为一个子模块放入git仓库

$ git submodule add

git://github.com/chneukirchen/rack.git rack

filter-branch

核弹级应用，尽可能小心使用可以从所有历史提交中删除一个文件，悔棋用，可能你误提交了个私密文件，可以通过这个功能来从历史提交中全部删除

git filter-branch --tree-filter 'rm -f passwords.txt'

HEAD

Code review

公司有个gerrit网站，用来做git代码的code review

https://scm.hz.netease.com

Code review流程：

Ø代码commit之后，push的地址是code review的地址，而不是仓库地址

Ø提交之后，owner就会收到code review的邮件，显示代码的改动

Ø可以在ui上review代码，并做评注

Ø Commiter就会收到邮件，修改并重新发起code

GIT,GITHUB,GITLAB的关系

gitHub是一个面向开源及私有软件项目的托管平台，因为只支持git 作为唯一的版本库格式进行托管，故名gitHub。

gitHub于2008年4月10日正式上线，除了git代码仓库托管及基本的 Web管理界面以外，还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱（报表）、代码片段分享（Gist）等功能。目前，其注册用户已经超过350万，托管版本数量也是非常之多，其中不乏知名开源项目 Ruby on Rails、jQuery、 python 等。

为啥选用GITLAB，不选用GITHUB？

提供 Git 项目仓库托管服务的有业界闻名的 GitHub，但你要将代码上传到

GitHub上面，而且将项目设为私有还要收费。而 GitLab 则是开源免费的（社区版免费，企业版需要订阅），同样是采用了 Ruby on Rails 开发，可以让你在自己的内网搭建一个"山寨版"的 GitHub。GitHub 的使用体验是诱人的，因此部署自己的 GitLab 就十分吸引人

大纲

Git简介 Git基础 Git操作

GIT版本管理

GIT分支管理在项目中的实践

GIT开分支

Git开分支代价非常小 Ø仅增加几十字节的存储

Ø开分支不需要管理员来开

Ø开分支仅需要数秒钟

创建分支

Git branch <branchName> 创建分支 git checkout <branchName> 切换分支

分支merge-ff

当一个分支是另一个分支的祖父节点，即从该分支分离后原来分支未做任何改变

分支merge-non-ff

当不满足fast-farward条件时，就会发生三方合并

衍合分支-rebase

衍合是另一种分支合并策略，会在当前分支上重演被衍合分支的历史，他是一种线性的合并

分支管理遇到的问题

多人并行开发，开分支需求多，但分支开销太大，只能凑合着用分支合并特别麻烦，项目后期经常为了合并分支要花费一下午的时间，特别是tree conflict 问题项目使用时间长后，svn服务器速度越来越慢，导致svn操作都很慢，喝杯咖啡回来继续

GIT的优势

使用GIT很大程度上解决了我们在项目中碰到的问题

Ø分支随意开，几乎0代价，鼓励大家并行开发

Ø本地分支，方便进行一些调研性的feature开发

Ø分支合并快，每天合并分支十来次，也没啥感觉

Ø图形化工具能方便管理分支，检查有无分支未被合并

Git在Datastream中的运用

Datastream项目从今年下半年开始正式使用 git作为代码管理的工具，摸索出了一些使用心得

Ø GIT虽然是一个分布式版本管理框架，理论上没有中心库的概念。但在实际应用中还是要有一个中心库，方便多人开发的代码做同步

Ø尽量多使用本地分支进行开发、单元测试，测试通过再合并到协同开发的分支上

项目分支管理策略

项目分支管理策略一共有以下一些分支

Ø Master:主干分支用于上线

Ø Release branches：预发布分支

Ø Develop：开发分支

Ø Hotfix branches:线上bug修复分支 Ø Feature branches:长期功能分支

分支-环境

如果仅仅有分支管理，还无法管理好一个大型的项目，需要针对不同的分支，有不同的环境对应

Ø开发环境->develop分支

Ø QA环境->Release分支、hotfix分支

Ø Per环境->性能测试相关的feature branch

Ø线上环境->Master分支

只有分支和环境对应关系理清楚，我们才能规划好每一步，否则还是一团乱

开发

Develop是一个长期分支，也是项目中最重要的一个分支，在项目里它主要承担协同开发、集成测试的作用。

开发人员在开发feature时，先本地开本地分

支进行开发和单元测试（如果该模块开发需要其他模块协助，也可以把这个本地分支push到远端），单元测试通过后merge到develop分支进行集成测试。

Develop分支不要求绝对稳定，但是也要保证一定的稳定度，至少新feature编译和单元测

测试

Release预发布分支一般会在项目有第一个 feature提交时开，主要用于QA测试只有develop分支集成测试通过的才可以提交到release分支供QA测试 QA如果在Release分支测试出有bug，最好的方式是通过Release上开个分支，修复bug，并借用下develop环境调试bug（这步过程需要协商），修复完成后merge到Release分支以及

Develop分支

上线

QA在Release分支测试通过后，会通过配置管理员将Release分支通过fast-forward模式

merge到master分支，这样不会有任何conflict。

Master分支上打TAG，然后部署上线。这样一个项目流程就结束了。

线上bug

当发现线上bug后，会开启一个hotfix分支，修复bug，并在QA环境上测试

测试通过后merge到master，部署上线并也要merge到develop分支

性能测试

项目过程中需要做性能测试的时候可以从

develop上拉一个性能测试的feature branch，例如perf 当有性能相关的feature提交的时候merge develop到perf

如果有性能问题需要修复，可以在perf上进行修复，并merge到develop

git使用过程遇到的问题

Git也存在一些问题

Ø没有目录的概念，因此不太容易对子目录控制权限

Ø可以使用submodule来控制权限，但是配置和管理代码的复杂度就会上升，分支管理会趋于复杂

Ø Merge的时候整个branch的代码一起merge，在 develop分支上有时会有部分人集成测试通过，部分人测试未通过的时候，这时候merge会出问题。目前通过沟通解决，merge之前通知所有人，如果有问题的人先把代码revert一下，大部分时候问题不大。

总结

GIT从很大程度减轻了项目过程中代码管理、分支管理的代价，非常适合大型项目的多人并发开发简单，可以让程序员不需要太多的代码分支管理技术也可以很好地管理代码，不容易出错高速，大部分的本地操作，让程序员不会浪费时间在等待svn操作上

Q& A