git入门

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管理了！牛是怎么定义的呢？大家可以体会一下。

Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。

历史就是这么偶然，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费而超级好用的Git了。

git的特点

集中式版本控制系统

集中化的版本控制系统（ Centralized Version Control Systems，简称 CVCS ）。这类系统，诸如 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法（见下图1）。

        这种系统最显而易见的缺点是中央服务器的单点故障。如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。要是中央服务器的磁盘发生故障，碰巧没做备份，或者备份不够及时，就会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，而被客户端偶然提取出来的保存在本地的某些快照数据就成了恢复数据的希望。但这样的话依然是个问题，你不能保证所有的数据都已经有人事先完整提取出来过。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。

分布式版本控制系统

        分布式版本控制系统（ Distributed Version Control System，简称 DVCS ）会把服务器上的代码仓库完整地镜像下来。这样每个人的电脑上都有一份完成的服务器代码仓库的镜像，任何一处协同工作用的服务器发生故障，事后都可以用个人的电脑上的像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份（见下图2）。我们可以看到电脑A与电脑B与服务器上的版本内容完全一致

git版本存储方式

        Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。这类系统（CVS，Subversion，Perforce，Bazaar 等等）每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容，请看下图。

其他系统在每个版本中记录着各个文件的具体差异

Git 并不保存这些前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一链接。Git 的工作方式就像图 4 所示。

 

Git 保存每次更新时的文件快照 

 近乎所有操作都是本地执行

在 Git 中的绝大多数操作都只需要访问本地文件和资源，不用连网。但如果用 CVCS 的话，差不多所有操作都需要连接网络。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快。

举个例子，如果要浏览项目的历史更新摘要，Git 不用跑到外面的服务器上去取数据回来，而直接从本地数据库读取后展示给你看。所以任何时候你都可以马上翻阅，无需等待。如果想要看当前版本的文件和一个月前的版本之间有何差异，Git 会取出一个月前的快照和当前文件作一次差异运算，而不用请求远程服务器来做这件事，或是把老版本的文件拉到本地来作比较。

用 CVCS 的话，没有网络或者断开 VPN 你就无法做任何事情。但用 Git 的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，等到了有网络的时候再上传到远程仓库。同样，在回家的路上，不用连接 VPN 你也可以继续工作。换作其他版本控制系统，这么做几乎不可能，抑或非常麻烦。比如 Perforce，如果不连到服务器，几乎什么都做不了（译注：默认无法发出命令 p4 edit file 开始编辑文件，因为 Perforce 需要联网通知系统声明该文件正在被谁修订。但实际上手工修改文件权限可以绕过这个限制，只是完成后还是无法提交更新。）；如果是 Subversion 或 CVS，虽然可以编辑文件，但无法提交更新，因为数据库在网络上。看上去好像这些都不是什么大问题，但实际体验过之后，你就会惊喜地发现，这其实是会带来很大不同的。

git安装》》》》》》》读者可以自己相信自己

git仓库的基本概念

1. 远程仓库（Remote）：

也叫作资源库，是远程机器上的代码库，用于做不同版本库文件交换更新。如Gitlab，GitHub，gitee。

1. 本地库（Repository）：

是用户在本地创建的目录，拥有远程库的一个快照，由工作区和版本库构成。

工作区（Workspace）：

本地库的根目录中除.git目录以外的内容，存储内容的实际文件。

暂存区（stage/Index）：

也叫做缓存区，暂存信息存放在.git目录"下的index文件（.git/index）中，用于临时保存内容的修改；

版本库（.git目录）

是本地库的根目录中的一个隐藏目录.git，用于记录版本信息，Git进行版本控制所需要的文件，则都放在.git文件夹中；

分支（Branch）：

本地库中默认创建一个主（master）分支，分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。

git蛮关键的地方是他的“回档”功能，它通过追踪该项目下的每一个文件，让它们能被git统一管理。

工作区就是自己的项目，./git是暂存区和本地仓库，文件由快照形式保存，可以通过指令回滚

git仓库的工作流程

从一般开发者的角度来看，使用Git的工作流程是：

1. 克隆远程库：从远程库上克隆完整的Git仓库（包括代码和版本信息）到本地；
2. 在本地库上修改代码：在本地库上根据不同的开发目的，创建分支，修改代码；
3. 提交到分支：在本地分支上提交代码；
4. 把修改合并到本地主分支：在本地库上提交更新，也就是说，把修改合并到本地主分支；
5. 把远程库合并到本地主分支：把远程库上的最新代码fetch下来，跟本地主分支合并，如果存在冲突，那么解决冲突。
6. 把本地主分支提交到远程库：生成补丁（patch），把补丁发送给远程库。

Git的命令

新建文件夹

git init

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

git remote add orgin 你希望提交到的网址

git pull orgin master

 git支持linux很多指令

 

git add 你的文件
git commit -m "一个注释，必须要写"

 

git push -u orgin master

好，到这里就能提交到gitee了，有报错再找报错吧，实在不行再新建一个

git rm --cached 想删除的文件

 

git status

当git创建文件没有commit时git status就会提醒你

git log

可以看到所有git日志，提交的时间和注释

 

根据各种日志，如果突然目前的有报错，我想回滚到之前的版本重新来。可以版本回滚

git reset --hard HEAD^

^就回滚一次，两次就^^

git reset –heard sha1

这样能根据日志回滚指定的版本，sha1是一串数字的前四个数字

config概述

在git中，我们使用git config 命令用来配置git的配置文件，git配置级别主要有以下3类：

1、仓库级别 local 【优先级最高】

2、用户级别 global【优先级次之】

3、系统级别 system【优先级最低】

git 仓库级别对应的配置文件是当前仓库下的.git/config 

git 用户级别对应的配置文件是用户宿主目录下的~/.gitconfig

git系统级别对应的配置文件是git安装目录下的 /etc/gitconfig

当然我们可以在cmd命令提示符中输入以下查看配置信息

git config --local -l

git config --global -l

git config --system -l

 gitignore 文件

在项目中，我们可能一起提交多个文件

·  git add -A  提交所有变化

·  git add -u  提交被修改(modified)和被删除(deleted)文件，不包括新文件(new)

·  git add .  提交新文件(new)和被修改(modified)文件，不包括被删除(deleted)文件

在使用git的过程中，一般我们总会有些文件无需纳入git的管理，也不希望它们总出现在未跟踪文件列表，这些文件通常是日志文件、临时文件、编译产生的中间文件、工具自动生成的文件等等。
此时我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件模式，Git会根据这些模式规则来判断是否将文件添加到版本控制中。
注意：在windows下可以创建文件名为.gitignore.，保存之后系统会自动重命名为 .gitignore

1. 1. 格式规范

  （1）所有空行或者以注释符号 ＃ 开头的行都会被 Git 忽略

  （2）可以使用标准的 glob 模式匹配

  （3）匹配模式最后跟斜杠(/)说明要忽略的是目录

  （4）要忽略指定模式以外的文件或目录，可以在模式前加上感叹号(!)进行取反

1. 1. glob模式

所谓的 glob 模式是指 shell 所使用的简化了的正则表达式，匹配规则如下：

"*"：星号匹配零个或多个任意字符

[]：匹配任何一个列在方括号中的字符，如[ab]匹配a或者匹配b

"?"：问号匹配一个任意字符

[n-m]：匹配所有在这两个字符范围内的字符，如[0-9]表示匹配所有0到9的数字

匹配示例

logs/：       忽略当前路径下的logs目录，包含logs下的所有子目录和文件

/logs.txt： 忽略根目录下的logs.txt文件

*.class：    忽略所有后缀为.class的文件

!/classes/a.class：不忽略classes目录下的a.class文件

tmp/*.txt： 只忽略tmp目录下的.txt文件

**/foo：   可以忽略/foo, a/foo, a/b/foo等

Git分支管理

Git 的默认分支就是 master。你所作的commit会在master分支上自动移动。 在多次提交操作之后，master分支指向最后那个commit object（提交对象链）。

Git 的 “master” 分支并特殊，跟其它分支没有区别。 之所以几乎每一个仓库都有 master 分支，是因为 git init 命令默认创建它。

但很多时候听别人说master分支，往往有一种 这个分支是稳定、无bug的分支。而develop往往预示这新功能，不稳定的分支。这和分支策略有关，但本质上这两个分支没区别

其实就是，工作区可以“存档读取换”，分支也可以切换，留一个稳定没事的，一个用来开发，出现问题就回滚。分支“读取存档”

分支创建

通过git branch来查看和创建分支。

创建标签记在HEAD指针所指向的提交点创建tag（就是当前所在分支）

git branch dev

         分支切换到dev

git checkout dev

         创建分支与切换分支同时完成

git checkout -b dev2

这是我们在dev2分支创建一个文件A.txt并且提交。我们发现在dev2分支可以看到这个文件，当我们切换会master时候无法看到这个文件。

 

 

分支删除

1. 不能删除自己所在的分支

        

         我们可以切换到master删除一个合并后的或者没有发生变化的分支

 

1. 如果一个分支发生了变化不能删除

 

分支合并

我们继续基于上面的例子，切换到master上做dev2 的合并

我们发现master分支上也添加了A.txt这个文件

         如果修改的是同一个文件也可以做同样的合并，让我们切换到dev2分支修改A.txt中的内容。在A.txt中添加了一行World

 

我们切换会master分支的时候发现提示了A.txt的变动。通过合并发现master分支上也合并了dev2修改的内容，合并之后dev2就删除就被允许了。

 分支的本质

master指向的是提交

HEAD是指向当前的分支，当前在哪个分支就指向哪个分支

第二张图上我们可以看到创建了dev的分支，当我们切换到dev分支的时候HEAD就会指向dev

当我们进入.git文件夹查看HEAD的内容的时候可以看到，所处分支不同内部的文件指向就不同。

master分支

dev2分支

git的分支与svn不同，svn是整体拷贝一份分支，git用的是指针。

如果dev发生修改提交，dev的版本就会向后移动。

在master分支上如果合并就会出现下面的图

分支的冲突 

我们在dev2分支里面修改A.txt文件添加一行 update by dev2后提交

我们在master分支里面修改A.txt文件同时添加一行 update by master后提交

 

合并时候我们发现出现冲突

<<<<<<<<<<<HEAD是当前指向的分支所修改

>>>>>>>>>>dev2是dev2分支修改

我们需要手工合并。修改后报了master的内容

 

我们可以通过图形来查看冲突的提交日志。

git log --graph

 

Git stash

1 当正在dev分支上开发某个项目，这时项目中出现一个bug，需要紧急修复，但是正在开发的内容只是完成一半，还不想提交，这时可以用git stash命令将修改的内容保存至堆栈区，然后顺利切换到hotfix分支进行bug修复，修复完成后，再次切回到dev分支，从堆栈中恢复刚刚保存的内容。

2 由于疏忽，本应该在dev分支开发的内容，却在master上进行了开发，需要重新切回到dev分支上进行开发，可以用git stash将内容保存至堆栈中，切回到dev分支后，再次恢复内容即可。

总的来说，git stash命令的作用就是将目前还不想提交的但是已经修改的内容进行保存至堆栈中，后续可以在某个分支上恢复出堆栈中的内容。这也就是说，stash中的内容不仅仅可以恢复到原先开发的分支，也可以恢复到其他任意指定的分支上。git stash作用的范围包括工作区和暂存区中的内容，也就是说没有提交的内容都会保存至堆栈中。

 

我们在master分支修改A.txt添加一行

这时我们要切换dev2分支

我们发现会提示错误，git建议我们先提交或者stash修改的内容再切换

我们执行

git stash

会先把修改的内容做保存然后我们就可以切换到其他的分支

列出stash保存的所有修改

我们切换回master分支执行，我们能看到上次保存的操作

git stash list

我们同样也可以再次修改文件去做stash，这样就会产生2条保存的记录

我们可以将stash过的修改恢复出来。通过pop取出最近的恢复并且删除stash中的修改

git stash pop

如果两次pop由于提一次没有做提交则会报错，所以我们应该把第一次pop的提交，在pop第二次的。

 

 分支整理策略

从上图可以看到主要包含下面几个分支：

         master：git默认主分支（这里不作操作）。

         stable：稳定分支，替代master，主要用来版本发布。

         develop：日常开发分支，该分支正常保存了开发的最新代码。

         feature：具体的功能开发分支，只与 develop 分支交互。

         release：release 分支可以认为是 stable分支的未测试版。比如说某一期的功能全部开发完成，那么就将 develop 分支合并到 release分支，测试没有问题并且到了发布日期就合并到 stable分支，进行发布。

         bugfix：线上 bug 修复分支。

主分支

因为master分支我们不作操作，所以针对stable和develop这两个主分支来讲解。

             stable分支：用来发布，管理着多个稳定的版本。

             develop分支：就是我们日常开发的分支。

   使用这两个分支就具有了最简单的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题后，则将 develop 分支的代码合并到 stable分支并发布。

 

 推送远程仓库

git remote add origin https://github.com/txjava-teach/txjava-code.git

添加后，远程库的名字就是origin，这是Git默认的名字，也可以改成别的，但是origin这个名字⼀看就知道是远程库。下一步，就可以把本地库的所有内容推送到远程库上:

然后先拉后推，

 git pull orgin master

然后推送本地库的文件。

git push -u origin master

远程分支查看

origin master关联的是远程的master分支，用于追踪远程分支的状态

查看远程分支

git branch -a

我们加上参数v可以查看本地分支和远程分支的最后提交

git branch -av

我们修改A.txt文件

我们通过git status可以看到我们master分支和远程分支origin/master都是最新的。

此时我们提交我们的修改后在查看git status，我们可以发现我们的本地master分支领先了1次提交。

从分支的详细信息中我们可以看到远程分支的提交版本和master的提交版本不同，本地领先了。

此刻我们把本次修改推送到远程，远程和本地便保持了版本的同步