1。基础命令
执行一下命令，可以将已经有的文件夹初始化成git仓库。其文件见下就是需要提交的文件。
""" >: cd 目标文件夹内部 >: git init """
或者可以这样创建git仓库
""" >: cd 目标目录 >: git init 仓库名 """
在仓库目录终端下 - 设置全局用户。
""" >: git config --global user.name '用户名' >: git config --global user.email '用户邮箱' 注：在全局文件 C:Users用户文件夹.gitconfig新建用户信息，在所有仓库下都可以使用
"""
>: git config user.name '用户名'
-- 用户名
>: git config user.email '用户邮箱'
-- 用户邮箱
注：在当前仓库下的config新建用户信息，只能在当前仓库下使用
注：一个仓库有局部用户，优先使用局部用户，没有配置再找全局用户
"""
"""
# 当仓库中有文件增加、删除、修改，都可以在仓库状态中查看
>: git status
-- 查看仓库状态
>: git status -s
-- 查看仓库状态的简约显示
"""
# 通过任何方式完成的文件删与改 # 空文件夹不会被git记录
"""
>: git checkout .
-- 撤销所有暂存区的提交
>: git checkout 文件名
-- 撤销某一文件的暂存区提交
用法：当前工作区下已经通过add添加到暂存区后，再修改工作区中的文件但还未提交到暂存区，此时想要之前提交到暂存区中的文件状态，可以使用该命令
注：使用 git checkout [commit id],会进入指针游离状态，需要加上文件名，才能恢复commit版本中的某个文件到工作区。
"""
"""
>: git add .
-- 添加项目中所有文件
>: git add 文件名
-- 添加指定文件
用法：当工作区修改了文件后，需要提交到本地库中时，需要提交到暂缓区中，使用该命令
"""
git diff
""" >: git diff
查看尚未缓存的改动
>:git diff --cached
查看已缓存的改动：
>：git diff HEAD
查看已缓存的与未缓存的所有改动
>: diff：git diff --stat
显示摘要而非整个
"""
"""
>: git reset HEAD .
-- 撤销所有暂存区的提交
>: git reset 文件名
-- 撤销某一文件的暂存区提交
用法：当代码使用add提交到暂缓区后，如何需要撤回这个操作，就使用git reset 将暂缓区的提交记录恢复到上一次add之前的状态
"""
# git commit -m "版本描述信息"
# git commit -a
跳过add暂缓区这一步直接提交到本地库
用法：提交代码致本地仓库，并注明提交信息
"""
回滚暂存区已经提交到版本库的操作：
查看历史版本：
>: git log
>: git reflog
查看时间点之前|之后的日志：
>: git log --after 2018-6-1
>: git log --before 2018-6-1
>: git reflog --after 2018-6-1
>: git reflog --before 2018-6-1
查看指定开发者日志
>: git log --author author_name
>: git reflog --author author_name
查看详细的日志
git log --oneline
查看拓扑图日志：
git log --graph
逆向显示所有日志
git log --reverse --oneline
回滚到指定版本：
回滚到上一个版本：
>: git reset --hard HEAD^
>: git reset --hard HEAD~1
回滚到上三个版本：
>: git reset --hard HEAD^^^
>: git reset --hard HEAD~3
回滚到指定版本号的版本：
>: git reset --hard 版本号
>: eg: git reset --hard 35cb292
重置暂存区的指定文件，与上一次commit保持一致，但工作区不变
git reset [file]
重置暂存区与工作区，与上一次commit保持一致
git reset --hard
重置当前分支的指针为指定commit，同时重置暂存区，但工作区不变
git reset [commit]
用法：可以用于误提交版本，想要清除版本记录的情况
重置当前分支的HEAD为指定commit，同时重置暂存区和工作区，与指定commit一致
git reset --hard [commit]
重置当前HEAD为指定commit，但保持暂存区和工作区不变
git reset --keep [commit]
新建一个commit，用来撤销指定commit，后者的所有变化都将被前者抵消，并且应用到当前分支
git revert [commit]
暂时将未提交的变化移除，稍后再移入
git stash
git stash pop
用法：当从工作区add到暂缓区时，其中有记录，需要将记录暂时缓存已进行其他操作时，使用stash命令将该记录保存
"""
二。过滤文件。
在仓库根目录下（与git一个文件夹）创建gitignore，在其中写入不需要的文件，即可过滤文件。
# .gitignore 文件 # 1）在仓库根目录下创建该文件 # 2）文件与文件夹均可以被过滤 # 3）文件过滤语法 """ 过滤文件内容 文件或文件夹名：代表所有目录下的同名文件或文件夹都被过滤 /文件或文件夹名：代表仓库根目录下的文件或文件夹被过滤 eg： a.txt：项目中所有a.txt文件和文件夹都会被过滤 /a.txt：项目中只有根目录下a.txt文件和文件夹会被过滤 /b/a.txt：项目中只有根目录下的b文件夹下的a.txt文件和文件夹会被过滤 """
三。创建远程仓库
本地配置线上的账号与邮箱
>: git config --global user.name "doctor_owen"
>: git config --global user.email "doctor_owen@163.com"
在本地初始化仓库(git init)，并完成项目的初步搭建(项目架构)(一般都是项目负责人完成项目启动)
这个过程就是git的基础部分的本地操作
3）采用 https协议 或 ssh协议 与远程git仓库通信提交提交代码(一般都是项目负责人完成)
i) https协议方式，无需配置，但是每次提交都有验证管理员账号密码
>: git remote add origin https://gitee.com/doctor_owen/luffy.git # 配置远程源
>: git push -u origin master # 提交本地仓库到远程源
ii) ssh协议，需要配置，配置完成之后就可以正常提交代码
>: git remote add origin git@gitee.com:doctor_owen/luffy.git # 配置远程源
>: git push -u origin master # 提交本地仓库到远程源
iii）查看源及源链接信息
>: git remote
>: git remote -v
iv）删除源链接
>: git remote remove 源名字
注：origin远程源的源名，可以自定义；master是分支名，是默认的主分支
"""
四。
前提：本地仓库已经创建且初始化完毕（代码已经提交到本地版本库）
本机命令，添加远程源：git remote add origin ssh@*.git
采用ssh协议的remote源
官网：https://gitee.com/help/articles/4181#article-header0
本机命令，生成公钥：ssh-keygen -t rsa -C "*@*.com"
邮箱可以任意填写
本机命令，查看公钥：cat ~/.ssh/id_rsa.pub
码云线上添加公钥：项目仓库 => 管理 => 部署公钥管理 => 添加公钥 => 添加个人公钥
命令：git push origin master
五。
""" 1）查看仓库已配置的远程源 >: git remote >: git remote -v 2）查看remote命令帮助文档 >: git remote -h 3）删除远程源 >: git remote remove 源名 eg: git remote remove origin 4）添加远程源 >: git remote add 源名 源地址 >: git remote add orgin git@*.git """
六。多分支操作
在分支上建立分支时间轴相同。
每个分支都有独立的空间，随着分支的切换而改变。
""" 1.创建分支 >: git branch 分支名 2.查看分支 >: git branch 3.切换分支 >: git checkout 分支名 4.创建并切换到分支 >: git checkout -b 分支名 5.删除分支 >: git branch -d 分支名 6.查看远程分支 >: git branch -a
7.合并指定分支到当前分支
git merge [branch]
8.选择一个commit，合并进当前分支
git cherry-pick [commit]
9.删除远程分支
git push origin --delete [branch-name]
git branch -dr [remote/branch]
"""
七。标签
如果你达到一个重要的阶段，并希望永远记住那个特别的提交快照，你可以使用 git tag 给它打上标签。
git tag -a v1.0
执行了以上命令后，当我们执行 git log --decorate 时，我们可以看到我们的标签了。。
如果我们忘了给某个提交打标签，又将它发布了，我们可以给它追加标签。
git tag -a v0.985fc7e7(commit版本号)
查看所有可用的标签
git tag
指定标签信息命令：
git tag -a <tagname>-m "runoob.com标签"
PGP签名标签命令：
git tag -s <tagname>-m "runoob.com标签"
八：git pull 和git clone git fetch的区别
clone ：git clone 会拉取指定的远程端库，但是不能进行修改远程端等操作，需要配置ssh密钥。
pull ：git pull 会拉取指定远程库的文件，并可以对远程仓库进行操作，需要配置之ssh。相当于 git fetch origin + git merge origin/master
fetch: 拉取远程仓库的改动但是不合并，需要手动merge进行合并。
参考博客：https://blog.csdn.net/naro7l/article/details/78900338
参考文献：https://www.runoob.com/git/git-tag.html
参考博客：https://www.cnblogs.com/miracle77hp/articles/11163532.html
九。大致图：
现在，注意当我们执行 git log --decorate 时，我们可以看到我们的标签了：
额外：
版本控制：
版本控制是一种记录若干文件内容变化，以便将来查阅特定版本修订情况的系统。在本书所展示的例子中，我们仅对保存着软件源代码的文本文件作版本控制管理，但实际上，你可以对任何类型的文件进行版本控制。
如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本（这或许是你非常渴望拥有的功能）。采用版本控制系统 （VCS）是个不错的选择。有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态。你可以比较文件的变化细节，查出最 后是谁修改了哪个地方，从而导致出现怪异问题，又是谁在何时报告了某个功能缺陷等等。使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改 的改删的删，你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。
本地版本控制：
许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单。不过坏处也不少：有时候会混淆所在的工作目录，一旦弄错文件丢了数据就没法撤销恢复。
为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。
其中最流行的一种叫做 rcs，现今许多计算机系统上都还看得到它的踪影。甚至在流行的 Mac OS X 系统上安装了开发者工具包之后，也可以使用 rcs 命令。它的工作原理基本上就是保存并管理文件补丁（patch）。文件补丁是一种特定格式的文本文件，记录着对应文件修订前后的内容变化。所以，根据每次 修订后的补丁，rcs 可以通过不断打补丁，计算出各个版本的文件内容。
集中的版本控制：
接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？于是，集中化的版本控制系统（ Centralized Version Control Systems，简称 CVCS ）应运而生。这类系统，诸如 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这 已成为版本控制系统的标准做法 。
这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
事分两面，有好有坏。这么做最显而易见的缺点是中央服务器的单点故障。如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。要 是中央服务器的磁盘发生故障，碰巧没做备份，或者备份不够及时，就还是会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，而被客户端 提取出来的某些快照数据除外，但这样的话依然是个问题，你不能保证所有的数据都已经有人事先完整提取出来过。本地版本控制系统也存在类似问题，只要整个项 目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
分布式版本控制：
于是分布式版本控制系统（ Distributed Version Control System，简称 DVCS ）面世了。在这类系统中，像 Git，Mercurial，Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜 像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份。
更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。
结论：git属于分布式的版本控制系统，它可以在无网络的情况下，根据操作本地仓库实现版本提交，再进行版本合并，其没次从远程拉取的可以说是历代的文件提交记录。
git原理：
若是理解了 Git 的思想和基本工作原理，用起来就会知其所以然。在开始学习 Git 的时候，请不要尝试把各种概念和其他版本控制系统（诸如 Subversion 和 Perforce 等）相比拟，否则容易混淆每个操作的实际意义。Git 在保存和处理各种信息的时候，虽然操作起来的命令形式非常相近，但它与其他版本控制系统的做法颇为不同。理解这些差异将有助于你准确地使用 Git 提供的各种工具。
git快照记录：
Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。这类系统 （CVS，Subversion，Perforce，Bazaar 等等）每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容
图 其他系统在每个版本中记录着各个文件的具体差异
Git 并不保存这些前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照 的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一链接。Git 的工作方式如图所示
这是 Git 同其他系统的重要区别。它完全颠覆了传统版本控制的套路，并对各个环节的实现方式作了新的设计。Git 更像是个小型的文件系统，但它同时还提供了许多以此为基础的超强工具，而不只是一个简单的 VCS。稍后在第三章讨论 Git 分支管理的时候，我们会再看看这样的设计究竟会带来哪些好处。
git操作本地化：
在 Git 中的绝大多数操作都只需要访问本地文件和资源，不用连网。但如果用 CVCS 的话，差不多所有操作都需要连接网络。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快。
举个例子，如果要浏览项目的历史更新摘要，Git 不用跑到外面的服务器上去取数据回来，而直接从本地数据库读取后展示给你看。所以任何时候你都可以马上翻阅，无需等待。如果想要看当前版本的文件和一个月 前的版本之间有何差异，Git 会取出一个月前的快照和当前文件作一次差异运算，而不用请求远程服务器来做这件事，或是把老版本的文件拉到本地来作比较。
用 CVCS 的话，没有网络或者断开 VPN 你就无法做任何事情。但用 Git 的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，等到了有网络的时候再上传到远程仓库。同样，在回家的路上，不用连接 VPN 你也可以继续工作。换作其他版本控制系统，这么做几乎不可能，抑或非常麻烦。比如 Perforce，如果不连到服务器，几乎什么都做不了（译注：默认无法发出命令p4 edit file 开始编辑文件，因为 Perforce 需要联网通知系统声明该文件正在被谁修订。但实际上手工修改文件权限可以绕过这个限制，只是完成后还是无法提交更新。）；如果是 Subversion 或 CVS，虽然可以编辑文件，但无法提交更新，因为数据库在网络上。看上去好像这些都不是什么大问题，但实际体验过之后，你就会惊喜地发现，这其实是会带来很大不同的。
git数据完整性如何保存
在保存到 Git 之前，所有数据都要进行内容的校验和（checksum）计算，并将此结果作为数据的唯一标识和索引。换句话说，不可能在你修改了文件或目录之后，Git 一无所知。这项特性作为 Git 的设计哲学，建在整体架构的最底层。所以如果文件在传输时变得不完整，或者磁盘损坏导致文件数据缺失，Git 都能立即察觉。
Git 使用 SHA-1 算法计算数据的校验和，通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值，作为指纹字符串。该字串由 40 个十六进制字符（0-9 及 a-f）组成，看起来就像是：
24b9da6552252987aa493b52f8696cd6d3b00373Git 的工作完全依赖于这类指纹字串，所以你会经常看到这样的哈希值。实际上，所有保存在 Git 数据库中的东西都是用此哈希值来作索引的，而不是靠文件名。
多数操作为添加操作
常用的 Git 操作大多仅仅是把数据添加到数据库。因为任何一种不可逆的操作，比如删除数据，都会使回退或重现历史版本变得困难重重。在别的 VCS 中，若还未提交更新，就有可能丢失或者混淆一些修改的内容，但在 Git 里，一旦提交快照之后就完全不用担心丢失数据，特别是养成定期推送到其他仓库的习惯的话。
这种高可靠性令我们的开发工作安心不少，尽管去做各种试验性的尝试好了，再怎样也不会弄丢数据。
结论：当git存储数据时，是以额外的文件存储，但是这样会浪费很多存储空间所以会将所有相同的文件形成软连接指向上一个版本，如此只要保存新增的数据变动即可，包括删除数据的变动，这样使得git提交的文件可以恢复。
文件的三种状态：
对于任何一个文件，在 Git 内都只有三种状态：已提交（committed），已修改（modified）和已暂存（staged）。已提交表示该文件已经被安全地保存在本地数据库 中了；已修改表示修改了某个文件，但还没有提交保存；已暂存表示把已修改的文件放在下次提交时要保存的清单中。
由此我们看到 Git 管理项目时，文件流转的三个工作区域：Git 的工作目录，暂存区域，以及本地仓库。
每个项目都有一个 Git 目录（译注：如果 git clone 出来的话，就是其中 .git 的目录；如果git clone --bare 的话，新建的目录本身就是 Git 目录。），它是 Git 用来保存元数据和对象数据库的地方。该目录非常重要，每次克隆镜像仓库的时候，实际拷贝的就是这个目录里面的数据。
从项目中取出某个版本的所有文件和目录，用以开始后续工作的叫做工作目录。这些文件实际上都是从 Git 目录中的压缩对象数据库中提取出来的，接下来就可以在工作目录中对这些文件进行编辑。
所谓的暂存区域只不过是个简单的文件，一般都放在 Git 目录中。有时候人们会把这个文件叫做索引文件，不过标准说法还是叫暂存区域。
结论；当从远程端clone或者拉取文件时，如何辨别哪个是可用的，直接git log查看该仓库的提交记录，只要提交记录符合远程仓库的提交记录，就可以做为工作空间进行提交和修改文件。