Git介绍

Git介绍

框架

1. 控制系统（VCSs）和 Git 的基本概念
2. Git 的基本使用
3. Git 的分支模型
4. 服务器端的 Git
5. 多种分布式工作流的细节
6. GitHub 托管服务以及深层次的工具
7. Git 的高级命令
8. Git 环境的自定义配置
9. 对比 Git 和其它 VCSs
10. 深入 Git 隐晦而漂亮的实现细节

背景

版本控制

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

许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单，但是特别容易犯错。 有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。

常用手段

RCS 的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。

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

DVCS（Distributed Version Control System）——分布式版本控制系统

特点

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

Git 和其它版本控制系统（包括 Subversion 和近似工具）的主要差别在于 Git 对待数据的方式。

其它大部分系统以文件变更列表的方式存储信息，这类系统（CVS、Subversion、Perforce、Bazaar 等等） 将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异 （它们通常称作基于差异（delta-based） 的版本控制）。

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

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

Git 保证完整性

Git 一般只添加数据

四种状态

未跟踪(Untracked)

没有加入到暂存区，需要通过git add 状态变成staged(已暂存)

已提交（committed）

表示修改了文件，但还没保存到数据库中。

已修改（modified）

表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。

已暂存（staged）

表示数据已经安全地保存在本地数据库中。

三个阶段

工作区、暂存区以及 Git 目录

工作流程

1. 在工作区中修改文件。

2. 将你想要下次提交的更改选择性地暂存，这样只会将更改的部分添加到暂存区。

3. 提交更新，找到暂存区的文件，将快照永久性存储到 Git 目录。

安装

配置

三份git配置文件，都在本地，换了电脑就没有了

系统级配置

~/etc/gitconfig: 系统全局配置文件，该配置文件中的配置选项对操作系统上所有使用git的用户产生影响，使用git config –system+配置方案后缀，可以针对此文件进行配置，一般在git的安装目录的etc文件夹中

全局级配置

~/.gitconfig: 用户全局配置文件，该配置文件的配置选项对当前用户产生影响，并且会覆盖掉系统全局配置文件中已经存在的配置选项，使用git config --global+配置方案后缀，可以针对此文件进行配置，win10中一般在C:Users<用户名>

仓库级配置

~/.git/config: 该文件存在每个git镜像下，其配置文件的配置选项仅对该git镜像产生影响，它会覆盖掉用户全局配置文件中已经存在的配置选项

版本流程

master：主分支；主要是稳定的版本分支，正式发布的版本都从Master拉

develop：开发分支；更新和变动最频繁的分支，正常情况下开发都是在Develop分支上进行的。

release：预发行分支；一般来说，代表一个版本的功能全部开发完成后递交测试，测试出Bug后进行修复的分支。

features：功能分支； 其实Features不是一个分支，而是一个分支文件夹。里面包含了每个程序员开发的功能点。Feature开发完成后合入Develop分支。

hotFix：最希望不会被创建的分支；这个分支的存在是在已经正式上线的版本中，发现了重大Bug进行修复的分支。