Pro Git阅读笔记

标签：安全   -name   https   变量   区别   等等   版本控制系统   ref   共享服务   

 一、什么是分布式版本控制系统

变迁： 本地版本控制系统（RCS）--> 集中化的版本控制系统(CVCS) --> 分布式版本控制系统(DVCS)

本地版本控制不利于多人协同合作  -->   集中化版本控制系统（服务器单点故障可能会丢失所有数据)  

--> 分布式版本控制系统(本地仓库是代码仓库的完全镜像，如果服务器故障，可以用本地仓库恢复)

二、Git与其他版本控制系统的区别

其他一些版本控制系统保存的信息是文件之间差异，而Git直接记录快照，而不是差异比较

Git是一个快照流，新的版本，对文件制作快照并保存这个快照的索引，如果文件没有修改，直接保存指向该文件的链接

1. Git操作快速得益于它的本地操作，很多操作不需要和服务器交互就能完成，比如查看项目的完整历史

同时在没网离线的环境下也能进行工作

2. Git所有数据在存储前都计算校验和，然后用校验和来引用

Git数据库中保存的信息都是以文件内容的哈希值(校验和)来引用，而不是文件名（40个十六进制字符组成）

比如:  

Git的三种状态

• 已提交(committed): 表示数据已经安全的保存在本地数据库中       git commit
• 已修改(modified)： 表示修改了文件，但还没保存到数据库中       
• 已暂存(staged)：    表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中  git add

 Git的三个工作区域

• Git仓库： 用来保存项目的元数据和对象数据库的地方，从其他计算机克隆仓库时，拷贝的就是这里的数据 .git目录
• 工作目录： 对项目的某个版本独立提取出来的内容，放在磁盘上供你使用或修改
• 暂存区域： 是一个文件，保存了下次将提交的文件列表信息

Git的基本工作流程    

1.  在工作目录中修改文件
2. 暂存文件，将文件的快照放入暂存区域
3. 提交更新，找到暂存区域的文件，将快照永久性存储到Git仓库目录

三、Git的安装使用

初次运行Git前的配置

配置文件在三个地方：

1. /etc/gitconfig文件:包含系统上每一个用户级他们仓库的通用配置。如果使用带有--system选项的git config时，它会从此文件读写配置变量
2. ~/.gitconfig或~/.config/git/config文件:只针对当前用户。可以传递--global选项让Git读写此文件
3. 当前使用仓库的Git目录中的configt文件(.git/config)：针对该仓库

每一个级别覆盖上一级别的配置，所以 .git/config的配置变量会覆盖/etc/gitconfig中的配置变量

配置用户信息

如果使用--global选项，该命令只需要运行一次，因为之后你再该系统上做任何事情，Git都会使用那些信息。

当你想针对特定项目使用不同的用户名称与邮件地址时，可以再哪个项目目录下运行没有--global选项的命令来配置。

检查配置信息:

可能会看到重复的变量，因为它会从不同的文件中读取同一个配置

具体查看某一项配置：

寻求命令帮助

ex.   git help config

 四、Git基础

 获取Git仓库(两种)

1. 在现有项目或目录下导入所有文件到Git中(想在本地已有项目建立仓库，并上传到服务器)

进入项目目录，然后输入命令:

该命令将创建一个名为.git的子目录，这个子目录含有你初始化的Git仓库中所有的必须文件，这些文件是Git仓库的骨干。

这里只是仅仅做了一个初始化的操作，项目中文件还没有被跟踪。

可以通过git add命令实现对制定文件的跟踪，然后执行git commit 提交:

2. 从一个服务器克隆一个现有的Git仓库

通过git clone [url]命令获得已经存在的Git仓库的拷贝:

会在当前目录下创建一个libgit2的目录，所有项目文件都在其中

如果想自定义本地目录名字:

本地仓库名字被自定义为mylibgit

本地工作目录中文件的两种状态:

• 已跟踪: 指那些被纳入了版本控制的文件，在上一次快照中有它们的记录
• 未跟踪：即不存在于上次快照记录中，也没有放入暂存区(一般指新创建的文件并没有git add)

文件的生命周期如下:

检查当前文件的状态

跟踪新文件

git add也可以接目录名，表示跟踪该目录下所有的文件

之后再查看文件的状态, 发现README已经在暂存区了

暂存已修改文件

git add 到暂存区，只是把想要commit的文件加入到一个列表中，表示这些文件需要commit

git add 理解为  "添加内容到下一次提交中"   注意暂存区就是一个文件

git add后再查看文件状态：

之后只需要进行git commit就可以同步到服务器中了

注意：在每次commit前都用 git status命令看下你具体提交了哪些文件

文件状态简览

git status -s   /   git status --short   可以得到更为紧凑的格式输出

新添加未跟踪文件  ？？        A 新添加到暂存区    右M  表示修改了但没有放到暂存区   

左M 表示修改了并且已经放到暂存区        MM  表示在工作区修改后加入到暂存区后又在工作区修改了 

忽略文件

设置哪些文件无需纳入Git的管理，也不希望它们总出现在未跟踪文件列表。

通常都是一些自动生成的文件，比如日志文件或者临时文件

创建一个名为.gitignore的文件，列出要忽略的文件模式

第一行表示  忽略所有以.o或.a结尾的文件

第二行表示   忽略所有以~结尾的文件

.gitignore规范：   正则表达式    /结尾表示文件目录   /开头表示防止递归   

#开头是注释      模式前加! 表示取反

例子:

 GitHub 有一个十分详细的针对数十种项目及语言的 .gitignore 文件列表       gitignore列表

五、 git 命令

git diff   

git diff通过文件补丁的格式显示具体哪些行为发生了改变

1. 查看尚未暂存的文件更新了哪些部分，不加参数直接输入git diff

$ git diff

比较的是工作目录中当前文件和暂存区快照之间的差异，就是修改后还没有暂存起来的变化内容

2. 查看已暂存的将要添加到下次提交的内容用

$ git diff --cached  或者
$ git diff --staged

git commit

暂存区准备妥当就可以提交了

每次准备提交前，先用git status看下，是不是都已暂存起来了，然后运行命令

$ git commit

这种方式会启动文本编辑器以便输入本次提交的说明  vim/emacs

用git config -global core.edtor命令设定喜欢的编辑器 ，默认为Vim

便捷操作 -m  选项  (表示message)

提交时记录的是放在暂存区域的快照。每一次运行提交操作，都是对项目做一次快照，以后可以回到这个状态或者进行比较

跳过使用暂存区域

git commit -a

git会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过git add步骤

移除文件

git移除某个文件，必须要从已跟踪文件清单中移除(从暂存区移除)，然后提交

用git rm命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中

1. 如果直接工作目录中手动删除，那么就会有unstaged信息：

2.再运行git rm记录此次移除文件的操作

下一次提交时，该文件就不再纳入版本管理了；如果不执行rm，即使删除了文件，它仍然还在版本管理中

3.当你想把文件从git仓库中删除，但仍然希望保留在当前工作目录中。也就是说，你想让文件保留在磁盘中，但不想让git继续跟踪，可以加入.gitignore或者

$ git rm --cached README

移动文件

$ git mv file_from file_to

这其实就是一个rename操作：

查看提交历史

git log命令

git log可以再在后面加上各种可选项用于不同功能

-p 显示每次提交的内容差异  -2 仅显示最近两次提交  --stat 看简略的统计信息  --pretty指定不同格式进行显示

作者是对代码进行修改的人，提交者是最后将此工作成功提交到仓库的人

--graph 添加了一些ASCII字符串来形象地展示你的分支及合并历史

还可以加一些其他的用于选择的选项

看一个实际的例子，

如果要查看 Git 仓库中，2008 年 10 月期间，Junio Hamano 提交的但未合并的测试文
件，可以用下面的查询命令：

 撤消操作

运行带--amend选项的提交命令尝试重新提交

例如，你提交后发现忘记了暂存某些需要的修改，可以像下面这样操作：

最终你只会有一个提交，第二次提交将代替第一次提交的结果

取消暂存的文件

git status命令会给出相应的命令提示

git reset HEAD <file>命令可以用来取消暂存

撤消对文件的修改

比如你在本地对文件进行了错误的修改，需要将它恢复到原来的样子(上一次提交)

git status中有提示命令：

通过git checkout -- <file>可以把本地修改的文件还原成暂存区的文件

 远程仓库的使用

查看远程仓库

如果想查看你已经配置的远程仓库服务器，可以运行git remote命令，通常是origin,这是git给克隆的仓库服务器的默认名字

git remote -v 会给出对应仓库的名字及其url

如果远程仓库不止一个，该命令会将它们全部列出。例如，与几个协作者合作的，拥有多个远程仓库的仓库像下面这样:

这样就可以轻松拉取其中任何一个用户的贡献

添加远程仓库

git remote add <shortname> <url> 添加一个新的远程git仓库，同时制定一个你可以轻松引用的简写

现在你可以在命令行中使用字符串 pb 来代替整个 URL。例如，如果你想拉取 Paul 的仓库中有但你没有的信
息，可以运行 git fetch pb：

从远程仓库中抓取与拉取

想从远程仓库中获得数据，可以执行：

这个命令会访问远程仓库，从中拉取所有你还没有的数据。执行完成后，你将会拥有那个远程仓库中所有分支的引用，可以随时合并或查看。

如果你使用 clone 命令克隆了一个仓库，命令会自动将其添加为远程仓库并默认以 “origin” 为简写。所以，git fetch origin 会抓取克隆（或上一次抓取）后新推送的所有工作。必须注意 git fetch 命令会将数据拉取到你的本地仓库 - 它并不会自动合并或修改你当前的工作。当准备好时你必须手动将其合并入你的工作。

如果你有一个分支设置为跟踪一个远程分支可以使用 git pull 命令来自动的抓取然后合并远程分支到当前分支。这对你来说可能是一个更简单或更舒服的工作流程；默认情况下，git clone 命令会自动设置本地 master 分支跟踪克隆的远程仓库的 master 分支（或不管是什么名字的默认分支）。运行 git pull 通常会从最初克隆的服务器上抓取数据并自动尝试合并到当前所在的分支。

所以说git fetch不会自动尝试合并只能自己手动合并， git full会自动尝试合并

推送到远程仓库

git push [remote-name] [branch-name]

默认情况下

只有当你有所克隆服务器的写入权限，并且之前没有人推送过时，这条命令才能生效。当你和其他人在同一时间克隆，他们先推送到上游然后你再推送到上游，你的推送就会毫无疑问地被拒绝。你必须先将他们的工作拉取下来并将其合并进你的工作后才能推送。

远程仓库的移除与重命名

重命名

移除

 打标签

git可以给历史中某一个提交打上一个标签，以示重要，比较有代表性的是会使用这个功能来标记发布结点(v1.0等等)

列出标签

以字母序列出 标签

 以特定的模式查找标签

创建标签

分两种

• 轻量标签：像一个不会改变的分支，是一个特定提交的引用
• 附注标签：是存储在git数据库中的一个完整对象，它们是可以被校验的，其中包括打标签者的名字，电子邮箱，日期时间，所以通常建议创建附注标签，这样可以拥有以上所有信息；如果想用一个临时的标签，或者因为其他原因不想要保存那些信息，可以选择轻量标签

创建附注标签

通过使用git show 可以看到标签信息与对应的提交信息

后期补上标签，需要在命令后加上相应的校验和或者部分校验和

共享标签

git push命令不会传送标签到远程仓库服务器上，所以在创建完标签后必须显式地推送标签到共享服务器上，这个过程就像共享远程分支一样

git push origin [tagname]

如果想一次性推送很多标签，直接使用 git push origin --tags就可以把所有不在远程仓库服务器上的标签全部传送到那里

 检出标签

在git中不能真的检出一个标签，但是想要工作目录与仓库中特定版本完全一样时，可以使用git checkout -b [branchname] [tagname]在特定的标签上创建一个新分支:

如果在这之后又进行了提交，version2分支会因为改动向前移动了，所以version2分支和v2.0.0标签稍微有点不同

也就是说标签不是快照，做不到完全检出

Pro Git阅读笔记

标签：安全   -name   https   变量   区别   等等   版本控制系统   ref   共享服务   

原文地址：http://www.cnblogs.com/lainey/p/7463906.html