git总结

简介

Git是一个开源的分布式版本控制系统

Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。

特点

Git把文件的每一个版本存储为blob文件

Git 与 SVN 区别点：

1、Git是分布式版本控制系统，SVN是集中式版本控制系统

2、git保存的是文件变化后的快照，svn保存对是文件的变化

集中式版本控制与分布式版本控制区别

集中式的版本库是集中存放在中央服务器的，要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。

集中式版本控制系统最大的毛病就是必须联网（局域网或互联网）才能工作。

分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了

git与github关系

GitHub是基于git的代码库托管站

github 是一个网站，用于广大开发者开源自己的代码

Git基本工作流程

工作区域划分

版本仓库：.git文件夹就是我们的本地版本库

暂存区：.git文件夹中的index文件就是暂存区，暂存已经修改的文件，最后统一提交到版本仓库

工作区：我们本地操作的文件位置就是工作去，添加，修改文件等动作

 

git add file1 是把文件从工作区提交到暂存区,git commit -m [message]提交暂存区到仓库区

 

.git文件夹介绍

使用git init命令后，会在当前文件夹下面建立隐藏的.git文件夹

这个文件夹里包含了git工作时所需要的所有信息，如果想从你的项目中移除git，但保留项目文件，只需要删除.git文件夹即可

 

目录结构：

hooks存放一些钩子脚本。

HEAD记录当前被checkout的分支。

objects存放所有数据。

refs 提交对象的指针。

description但是GitWeb专用的文件。

info文件夹是全局性排除文件，它和.gitignore是互补的。里面就一个exclude文件。

 

git会在objects里存放快照信息，定期会优化，保证快照空间，和读取时间的平衡。

每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一链接。

这么做的优点就是，Git的几乎所有操作都是本地操作，你可以即使不联网，你依然可以查看历史，而本地操作的另一个优点就是快！尤其在网络条件差的时候，这个优点更明显。比较变更，提交修改，等到有网络时一次性传上去

 

tag说明

tag是git版本库的一个标记，指向某个commit的指针。

tag主要用于发布版本的管理，一个版本发布之后，我们可以为git打上 v.1.0.1 v.1.0.2 ...这样的标签。

tag感觉跟branch有点相似，但是本质上和分工上是不同的：

tag 对应某次commit, 是一个点，是不可移动的。

branch 对应一系列commit，是很多点连成的一根线，有一个HEAD 指针，是可以依靠 HEAD 指针移动的。

所以，两者的区别决定了使用方式，改动代码用 branch ,不改动只查看用 tag。

 

命令行操作

Git初始化及仓库创建和操作

1、Git安装之后需要进行一些基本信息设置

　　a、设置用户名：git  config -- global  user.name  '你在github上注册的用户名';

　　b、设置用户邮箱：git  config -- global  user.email  '注册时候的邮箱';

 

注意：该配置会在github主页上显示谁提交了该文件

c、配置ok之后，我们用如下命令来看看是否配置成功

　　git config --list

注意：git  config --global 参数，有了这个参数表示你这台机器上所有的git仓库都会使用这个配置，当然你也可以对某个仓库指定不同的用户名和邮箱

2、初始化一个新的git仓库

　　a、创建文件夹

　　　　方法一：可以鼠标右击-》点击新建文件夹test1

　　　　方法二：使用git新建：$  mkdir test1

b、在文件内初始化git（创建git仓库）

　　　　方法一：直接输入 $ cd test1

　　　　方法一：点击test1文件下进去之后-》鼠标右击选择Git Bash Here->输入$ git init

这样就会在文件夹下出现一个隐藏的文件夹

3、向仓库中添加文件　　

　　方法一：用打开编辑器新建index.html文件

方法二：使用git命令。$  touch '文件名'，然后把文件通过$ git add '文件名'添加到暂存区，最后提交操作

4、修改仓库文件

　　方法一：用编辑器打开index.html进行修改

　　方法二：使用git命令。$  vi  '文件名'，然后在中间写内容，最后提交操作

5、删除仓库文件

　　方法一：在编辑器中直接把要删除的文件删除掉

　　方法二：使用git删除：$ git rm '文件名'，然后提交操作

Git管理远程仓库

 

使用远程仓库的目的：备份、实现代码共享集中化管理

Git远程仓库实际上就是保存在服务器上的git仓库文件

Git克隆操作

 

目的：将远程仓库（github上对应的项目）复制到本地

git clone 仓库地址

仓库地址由来如下：

克隆项目

同步仓库

将本地仓库同步到git远程仓库中：git push

期间出现错误的情况有：　

　a、出现提交错误

解决：这是通过Git GUI进行提交时发生的错误，由 .git 文件夹中的文件被设为“只读”所致，将 .git 文件夹下的所有文件、文件夹及其子文件的只读属性去掉即可。

b、如果出现无法同步或没有权限，解决方法如下：

git忽略文件

编辑.gitignore文件来设置要忽略的文件或文件夹

语法

以斜杠"/"开头表示目录；"/"结束的模式只匹配文件夹以及在该文件夹路径下的内容，但是不匹配该文件；"/"开始的模式匹配项目跟目录；如果一个模式不包含斜杠，则它匹配相对于当前 .gitignore 文件路径的内容，如果该模式不在 .gitignore 文件中，则相对于项目根目录。

以星号“*”通配多个字符；

以问号“?”通配单个字符

以方括号“[]”包含单个字符的匹配列表；

以叹号“!”表示不忽略(跟踪)匹配到的文件或目录；

 

# 以'#'开始的行，被视为注释.                                                                                                                          

 

# 忽略掉所有文件名是 foo.txt的文件.

foo.txt

 

# 忽略所有生成的 html文件,

*.html

 

# foo.html是手工维护的，所以例外.

!foo.html

 

# 忽略所有.o和 .a文件.

*.[oa]

 

常用的规则：

1）/mtk/               过滤整个文件夹

2）*.zip                过滤所有.zip文件

3）/mtk/do.c         过滤某个具体文件

 

设置用户名和邮箱

1.找到对应项目下的.git文件夹

2.打开config文件，添加如下配置：

[user]

name = 你的git名称

email = 你的git邮箱

之后进行下次提交时就使用修改后的用户名和邮箱了

多分支管理

分支命名与作用

master(主分支)：对应生产环境

所有用户可见的正式版本，部署生产环境的分支

主分支作为稳定的唯一代码库，不做任何开发使用。

只有一个master分支

输出：

输入：release上代码测试通过后合并到此，紧急bug修改后修复bug的分支合并到此

 

 

release(预发布分支)：对应预发布环境

release 为预上线分支，用于部署到预上线环境。

输入：

输出：合并到master分支

一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。

如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。

 

预发布分支是从Develop分支上面分出来的，测试问题修复结束以后，必须合并进Develop和Master分支。

它的命名，可以采用release-*的形式

 

test(测试分支):对应测试环境

test作为测试分支，对应测试环境代码

 

develop、dev(开发分支)：对应开发环境

开发分支只提供拉取，不进行实际开发。

develop 为测试分支，用于部署到测试环境

一般开发的新功能时，feature分支都是基于develop分支下创建的，始终保持代码新于master以及bug修复后的代码。一定是满足测试的代码才能往上面合并或提交。

feature(功能分支)：

开发新功能时，以develop为基础创建feature分支。

开发feature完成，merge回develop。

分支命名: feature-*

hotfix、fixbug(修补bug分支)：

bug修复分支，用于修复bug。

基于有bug的分支创建分支，修复完成后，再合并到存在bug的分支，

如果是对

 

一旦修复上线，便将其删除。

分支命名: hotfix-*、fixbug-*。

 

 

分支的配合使用

新需求加入

有一个订单管理的新需求需要开发，首先要创建一个 feature-order 分支，问题来了，该分支是基于哪个分支创建？

如果 存在 未测试完毕的需求，就基于 master 创建。

如果 不存在 未测试完毕的需求，就基于 develop 创建。

 

需求在 feature-order 分支开发完毕，准备提测时，要先确定 develop 不存在未测试完毕的需求，这时研发人员才能将将代码合并到 develop （测试环境）供测试人员测试。

 

测试人员在 develop （测试环境） 测试通过后，研发人员再将代码发布到 release （预上线环境）供测试人员测试。

 

测试人员在 release （预上线环境）测试通过后，研发人员再将代码发布到 master （正式环境）供测试人员测试。

 

测试人员在 master (正式环境) 测试通过后，研发人员需要删除 feature-order 分支。

 

迭代开发

 

修复测试环境 Bug

在develop分支新开

在 feature-order 分支上完成修复，之后合并到develop分支

修改预上线环境 Bug

从develop

在 feature-order 分支上完成修复，之后合并到develop分支，之后合并到release分支

修改正式环境bug

在 feature-order 分支上完成修复，之后合并到develop分支，之后合并到release分支,之后合并到master。

 

 

修改正式环境紧急bug

在测试环节未测试出 Bug，上线运行一段时候后出现了 Bug，需要紧急修复没时间在测试环境验证的。

如果 release 分支存在未测试完毕的需求，就基于 master 创建 hotfix-xxx 分支，修复完毕后发布到 master 验证，验证完毕后，将 master 代码合并到 release 和 develop 分支，同时删掉 hotfix-xxx 分支。

 

如果 release 分支不存在未测试完毕的需求，但 develop 分支存在未测试完毕的需求，就基于 release 创建 hotfix-xxx 分支，修复完毕后发布到 release 验证，后面流程与上线流程一致，验证完毕后，将 master 代码合并到 develop 分支，同时删掉 hotfix-xxx 分支。

 

如果 release 和 develop 分支都不存在未测试完毕的需求， 就直接在 develop 分支上修复完毕后，发布到 release 验证，后面流程与上线流程一致。

不同上线时间多分支开发

功能A要求5号上线，功能B要求10号上线，

A开一个dev分支，B开一个dev分支，A开发测试完成后合并到release分支，测试完成后合并到master分支；

合并release到B的dev分支上，避免B开发完成后合并到release分支时把A开发的内容给覆盖掉。