Git笔记(1) | 青训营笔记这是我参与「第五届青训营」伴学笔记创作活动的第 5 天分布式版本控制工具版本控制

这是我参与「第五届青训营」伴学笔记创作活动的第 5 天 分布式版本控制工具

版本控制

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

是一种在开发的过程中用于管理我们对文件、目录或工程等内容的修改历史，

方便查看更改历史记录，备份以便恢复以前的版本的软件工程技术。

特点

直接记录快照，而非差异比较

在 Git 中，每当你提交更新或保存项目状态时，它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。为了效率，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。

Git 对待数据更像是一个快照流。
近乎所有操作都是本地执行

因为你在本地磁盘上就有项目的完整历史，所以大部分操作看起来瞬间完成。效率比较高与集中式相比
Git 保证完整性

Git 中所有的数据在存储前都计算校验和，然后以校验和来引用。

Git 用以计算校验和的机制叫做 SHA-1 散列（hash，哈希）。这是一个由 40 个十六进制字符（0-9 和 a-f）组成的字符串，基于 Git 中文件的内容或目录结构计算出来。

SHA-1 哈希看起来是这样： 24b9da6552252987aa493b52f8696cd6d3b00373 -》绝对唯一

Git 中使用这种哈希值的情况很多，你将经常看到这种哈希值。实际上，Git 数据库中保存的信息都是以文件内容的哈希值来索引，而不是文件名。
Git 一般只添加数据

一旦你提交快照到 Git 中，就难以再丢失数据，特别是如果你定期的推送数据库到其它仓库的话。

概述

开发中的实际场景

场景一：备份
小明负责的模块就要完成了，就在即将Release之前的一瞬间，电脑突然蓝屏，硬盘光荣牺牲！几个月  来的努力付之东流

场景二：代码还原
这个项目中需要一个很复杂的功能，老王摸索了一个星期终于有眉目了，可是这被改得面目全非的  代码已经回不到从前了。什么地方能买到哆啦A梦的时光机啊？

场景三：协同开发
小刚和小强先后从文件服务器上下载了同一个文件：Analysis.java。小刚在Analysis.java   文件中的第30行声明了一个方法，叫count()，先保存到了文件服务器上；小强在Analysis.java文件中的  第50行声明了一个方法，叫sum()，也随后保存到了文件服务器上，于是，count()方法就只存在于小刚的记  忆中了

场景四：追溯问题代码的编写人和编写时间！
老王是另一位项目经理，每次因为项目进度挨骂之后，他都不知道该扣哪个程序员的工资！就拿这  次来说吧，有个Bug调试了30多个小时才知道是因为相关属性没有在应用初始化时赋值！可是二胖、王东、刘  流和正经牛都不承认是自己干的！

背景

Git是分布式的,Git不需要有中心服务器，我们每台电脑拥有的东西都是一样的。我们使用Git并且有个中心服务器，仅仅是为了方便交换大家的修改，但是这个服务器的地位和我们每个人的PC是一样的。我们可以把它当做一个开发者的pc就可以就是为了大家代码容易交流不关机用的。没有它大家一样可以工作，只不过“交换”修改不方便而已。

git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。Git是Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众多的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002 年间）。到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。

到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了

Linux 内核社区免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux 的缔造者Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。他们对新的系统制订了若干目标：

速度

简单的设计

对非线性开发模式的强力支持（允许成千上万个并行开发的分支）完全分布式

有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

工作区域

Git本地有三个工作区域：

工作目录（Working Directory）

暂存区(Stage/Index)

资源库(Repository 或Git Directory)。

如果在加上远程的git仓库(Remote Directory) / GITHUB GITEE

就可以分为四个工作区域。

文件在这四个区域之间的转换关系如下：

Workspace：工作区，就是你平时存放项目代码的地方

Index / Stage：暂存区，用于临时存放你的改动，事实上它只是一个文件，保存即将提交到文件列表信息

Repository：仓库区（或本地仓库），就是安全存放数据的位置，这里面有你提交到所有版本的数据。

其中HEAD(头指针）指向最新放入仓库的版本

Remote：远程仓库，托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换

Git工作流程图

1.  clone（克隆）: 从远程仓库中克隆代码到本地仓库
2.  checkout （检出）:从本地仓库中检出一个仓库分支然后进行修订
3.  add（添加）: 在提交前先将代码提交到暂存区
4.  commit（提交）: 提交到本地仓库。本地仓库中保存修改的各个历史版本
5.  fetch (抓取) ： 从远程库，抓取到本地仓库，不进行任何的合并动作，一般操作比较少。
6.  pull (拉取) ： 从远程库拉到本地库，自动进行合并(merge)，然后放到到工作区，相当于 fetch+merge
7.  push（推送） : 修改完成后，需要和团队成员共享代码时，将代码推送到远程仓库

git的工作流程一般是这样的：