Git版本控制的使用
为什么需要版本控制？
软件的开发过程中：
开发完成一个版本1后，打包，部署。
然后继续开发，定制新功能，增加新代码…
某一天，需要再打包一个 版本1.此时项目中已经新增了很多代码，甚至而且还有好多新代码尚在开发测试中…
开发过程中，完成了一个功能A。
继续写其他功能，增加新代码…
某一天，突然发现新功能的实现，就是一堆垃圾，完全不能使用，项目代码需要恢复到 刚写完功能A的状态…
某一天，突然发现新功能被砍啦，项目代码需要恢复到 刚写完功能A的状态…
某一天，突然发现接到新任务，需要对功能A进行改进，然后打包，部署，而此时项目中功能B的代码已然很多，且功能B尚未完成…
everything-is-local
Git是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。
Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。Git是目前世界上最先进的分布式版本控制系统（没有之一)
官网：https://git-scm.com/
文档：https://git-scm.com/book/zh/v2
版本控制发展：
原始的版本控制：项目写完一个功能，就复制一个项目副本。进而有多个项目的版本，可以通过不同的文件夹切换不同版 本。此种方案会有大量的文件出现，且不适合长线作业，终会陷入管理混乱
本地化的版本控制：引入一些管理软件，帮助管理本地的多个版本。此种方案不能共享他人，不能多人协同开发
集中化的版本管理：一个版本服务器，多个贡献者，贡献者将代码提交到服务器，并从服务器下载他人的代码。 此种版本可以协同开发。典型工具如
Subversion,CVS。但由于版本控制集中在服务器中所以存 在单点故障问题。分布式版本管理：多个贡献者本地都有完整的控制版本功能，可进行版本管理。且通过一个版本服务器共享彼此的代码。 是本地化和集中化的汇总。好处：没有单点问题，不强制依赖服务器，不强制依赖网络环境。典型工具 如
Git
| 下载git | 下载TortoiseGit |
|---|---|
一、 安装
Git安装除了安装位置外，其他一直下一步即可。
# 安装后，打开cmd ，自报家门 # 如下信息会在提交代码时要使用，记录在你的每次提交中。以后才知道哪次提交是谁做的，"git log"可以查看 # 执行： git config --global user.name "Your Name" #用户名 git config --global user.email "[email protected]" #邮箱 # 查看信息 git config -l测试：cmd中执行
git version查看git版本
二、 仓库
对应的就是一个
目录，这个目录中的所有文件被git管理起来。以后会将一个
项目的根目录，作为仓库。仓库中的每个文件的修改、删除 git都能跟踪。
2.1 基本指令 (重点)
**创建版本仓库：**创建一个文件夹，cmd指向该文件夹，然后执行
git init即可
.git目录保存仓库的所有内容**新增文件：**在文件夹中创建一个文件: xx.txt ，然后cmd执行该文件夹，
执行
git add xx.txt增加一个文件
git add xx.txt xx2.txt增加多个文件
git add abc增加当库目录下的abc目录中的所有文件
git add .增加库目录中所有文件提交文件：
git commit -m "this is a test file"【-m 后是对本次提交的描述】【提交添加的所有文件】
git commit hello.txt hello2.txt -m "this is a test file"提交某些文件
git commit -a -m "this is a test file"自动add并commit所有已跟踪并修改或删除的文件文件状态：
git status在提交后，如果文件有改动，可以看到文件改动：
git diff hello.txt查看该文件的改动情况注意：每次对库中内容改动后，都需要 add 和 commit操作，同步git，git中会记录当前仓库的快照(版本)。
删除文件：
git rm hello.txt并git commit hello.txt -m "xxx"即可
帮助：
git help commit或git commit --help
2.2 日志 - 提交历史 （重点）
每次 commit，随着版本的记录，也会留下日志。
执行：
git log# 显示从最早的提交点 到 当前提交点的 日志
git log --oneline#简洁日志显示
git log --oneline -2#简洁日志显示,最近2次提交日志
git log --oneline --graph#图形化显示分支走向
# commitID 描述
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append xxx
e475afc93c209a690c39c13a46716e8fa000c366 add words
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 add one line
注意git的
commitID是通过SHA1计算出来的一个非常大的数字，用十六进制表示，在分布式中保证唯一。
2.3 版本回退（了解）
每次的修改文件并add、commit 。git中也会记录一个版本。如果有需要可以回退到之前的一个数据版本状态。
执行：
git reset --hard HEAD~# 回退到上一个版本
git reset --hard HEAD~~# 回退到上上一个版本
git reset --hard HEAD~5# 回退到上5个版本
执行：
git rest --hard e475a#回退到commitID 为 "e475a…"的版本， commitID可以只写前几位，唯一即可。e475afc93c209a690c39c13a46716e8fa000c366=commitID, e475a是commitID的前几位
总结：1> 每次commit，git都会保留一个版本，每个版本都有一个全局唯一的commitID
2> git有个游标：HEAD，指向当前的版本，所以可以移动游标来回退版本
3> 也可以通过 commitID 回退到某个版本
4> 回退并不会删除任何版本，所以版本间可以来回切换
细节：发生版本回退后，通过
git log只能看到最原始提交点 至 当前提交点的 日志。git reflog可以看全部日志
三、架构
3.1 结构组成（重点）
仓库：就是第二章中，执行了
git init的目录
版本库：工作区中有一个隐藏目录
.git，这个目录不属于工作区，而是git的版本库，是git管理的所有内容暂存区：版本库中包含一个临时区域，保存下一步要提交的文件。
分支：版本库中包含若干分支，提交的文件存储在分支中
| 工作区-版本库-暂存区 |
|---|