大家好！我是民工哥。
对于 Git，置信大多数程序员并不会感到生疏。
作为目前世界上最先进的分布式版本控制系统（没有之一），Git 是一个开源的分布式版本控制软件, 用以无效、高速的解决从很小到十分大的我的项目版本治理。Git 最后是由 Linus Torvalds 设计开发的，用于治理 Linux 内核开发。随着工夫的推移，Git 倒退到明天，曾经成为了泛滥开发者必备的开发工具。
如果你平时学习 Git 时感觉到枯燥乏味，无妨试一试这个好玩的小游戏，通过别一种形式，在娱乐中去学习。
上面是其中的演示例子：
须要这款游戏的读者能够点击下方公众号名片回复关键词 Git 小游戏 获取
Git 简介
Git 是一个开源的分布式版本控制系统。
什么是版本控制？
版本控制是一种记录一个或若干文件内容变动，以便未来查阅特定版本订正状况的零碎。
什么是分布式版本控制系统？
介绍分布式版本控制系统前，有必要先理解一下传统的集中式版本控制系统。
集中化的版本控制系统，诸如 CVS，Subversion 等，都有一个繁多的集中管理的服务器，保留所有文件的订正版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。
这么做最不言而喻的毛病是地方服务器的单点故障。如果宕机一小时，那么在这一小时内，谁都无奈提交更新，也就无奈协同工作。要是地方服务器的磁盘产生故障，碰巧没做备份，或者备份不够及时，就会有失落数据的危险。最坏的状况是彻底失落整个我的项目的所有历史更改记录。
分布式版本控制系统的客户端并不只提取最新版本的文件快照，而是把代码仓库残缺地镜像下来。这么一来，任何一处协同工作用的服务器产生故障，预先都能够用任何一个镜像进去的本地仓库复原。因为每一次的提取操作，实际上都是一次对代码仓库的残缺备份。
可参考：Git 从入门到精通
Git vs SVN
Git 和 SVN 孰优孰好，每个人有不同的体验。
Git 是分布式的，SVN 是集中式的
这是 Git 和 SVN 最大的区别。若能把握这个概念，两者区别根本搞懂大半。因为 Git 是分布式的，所以 Git 反对离线工作，在本地能够进行很多操作，包含接下来将要重磅推出的分支性能。而 SVN 必须联网能力失常工作。
- Git 简单概念多，SVN 简略易上手
所有同时把握 Git 和 SVN 的开发者都必须抵赖，Git 的命令切实太多了，日常工作须要把握 add,commit,status,fetch,push,rebase 等，若要熟练掌握，还必须把握 rebase 和 merge 的区别，fetch 和 pull 的区别等，除此之外，还有 cherry-pick，submodule，stash 等性能，仅是这些名词听着都很绕。
在易用性这方面，SVN 对于老手来说会更有好一些。然而从另外一方面看，Git 命令多意味着性能多，若咱们能把握大部分 Git 的性能，领会到其中的奥秘，会发现再也回不去 SVN 的时代了。
- Git 分支便宜，SVN 分支低廉
在版本治理里，分支是很常应用的性能。在公布版本前，须要公布分支，进行大需要开发，须要 feature 分支，大团队还会有开发分支，稳固分支等。在大团队开发过程中，经常存在创立分支，切换分支的求。
Git 分支是指针指向某次提交，而 SVN 分支是拷贝的目录。这个个性使 Git 的分支切换十分迅速，并且创立老本非常低。
而且 Git 有本地分支，SVN 无本地分支。在理论开发过程中，常常会遇到有些代码没写完，然而需紧急解决其余问题，若咱们应用 Git，便能够创立本地分支存储没写完的代码，待问题解决完后，再回到本地分支持续实现代码。
更多关注 Git 与 Svn 的比拟请参阅：通俗易懂|用好 Git 和 SVN , 轻松驾驭版本治理
Git 工作原理
文字不好了解，请看 图文详解 Git 工作原理
Git 装置
- Debian/Ubuntu 环境装置
如果你应用的零碎是 Debian/Ubuntu，装置命令为：
$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
> libz-dev libssl-dev
$ apt-get install git-core
$ git --version
git version 1.8.1.2- Centos/RedHat 环境装置
如果你应用的零碎是 Centos/RedHat，装置命令为：
$ yum install curl-devel expat-devel gettext-devel \
> openssl-devel zlib-devel
$ yum -y install git-core
$ git --version
git version 1.7.1- Windows 环境装置
在 Git 官网下载地址下载 exe 安装包。依照装置向导装置即可。
倡议装置 Git Bash 这个 git 的命令行工具。
- Mac 环境装置
在 Git 官网下载地址下载 mac 安装包。依照装置向导装置即可。
Git 配置
Git 自带一个 git config 的工具来帮忙设置管制 Git 外观和行为的配置变量。这些变量存储在三个不同的地位：
/etc/gitconfig 文件: 蕴含零碎上每一个用户及他们仓库的通用配置。如果应用带有 --system 选项的 git config 时，它会从此文件读写配置变量。\~/.gitconfig 或 \~/.config/git/config 文件：只针对以后用户。能够传递 --global 选项让 Git 读写此文件。以后应用仓库的 Git 目录中的 config 文件（就是 .git/config）：针对该仓库。
每一个级别笼罩上一级别的配置，所以 .git/config 的配置变量会笼罩 /etc/gitconfig 中的配置变量。
在 Windows 零碎中，Git 会查找 $HOME 目录下（个别状况下是 C:\Users\$USER）的 .gitconfig 文件。Git 同样也会寻找 /etc/gitconfig 文件，但只限于 MSys 的根目录下，即装置 Git 时所选的指标地位。
Git 基本概念
- 版本库
当你一个我的项目到本地或创立一个 git 我的项目，我的项目目录下会有一个暗藏的 .git 子目录。这个目录是 git 用来跟踪治理版本库的，千万不要手动批改。
- 哈希值
Git 中所有数据在存储前都计算校验和，而后以校验和来援用。这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。这个性能建构在 Git 底层，是形成 Git 哲学不可或缺的局部。若你在传送过程中失落信息或损坏文件，Git 就能发现。
Git 用以计算校验和的机制叫做 SHA-1 散列（hash，哈希）。这是一个由 40 个十六进制字符（0-9 和 a-f）组成字符串，基于 Git 中文件的内容或目录构造计算出来。SHA-1 哈希看起来是这样：
24b9da6552252987aa493b52f8696cd6d3b00373
Git 中应用这种哈希值的状况很多，你将常常看到这种哈希值。实际上，Git 数据库中保留的信息都是以文件内容的哈希值来索引，而不是文件名。
- 文件状态
在 GIt 中，你的文件可能会处于三种状态之一：
- 已批改（modified） – 已批改示意批改了文件，但还没保留到数据库中。
- 已暂存（staged） – 已暂存示意对一个已批改文件的以后版本做了标记，使之蕴含在下次提交的快照中。
- 已提交（committed） – 已提交示意数据曾经平安的保留在本地数据库中。
- 工作区域
与文件状态对应的，不同状态的文件在 Git 中处于不同的工作区域。
- 工作区（working）– 当你 git clone 一个我的项目到本地，相当于在本地克隆了我的项目的一个正本。工作区是对我的项目的某个版本独立提取进去的内容。这些从 Git 仓库的压缩数据库中提取进去的文件，放在磁盘上供你应用或批改。
- 暂存区（staging）– 暂存区是一个文件，保留了下次将提交的文件列表信息，个别在 Git 仓库目录中。有时候也被称作 `‘索引’’，不过个别说法还是叫暂存区。
- 本地仓库（local） – 提交更新，找到暂存区域的文件，将快照永久性存储到 Git 本地仓库。
- 近程仓库（remote） – 以上几个工作区都是在本地。为了让他人能够看到你的批改，你须要将你的更新推送到近程仓库。同理，如果你想同步他人的批改，你须要从近程仓库拉取更新。
- 分支（Branch）
分支是为了将批改记录的整个流程离开存储，让离开的分支不受其它分支的影响，所以在同一个数据库里能够同时进行多个不同的批改
主分支（Master）后面提到过 master 是 Git 为咱们主动创立的第一个分支，也叫主分支，其它分支开发实现后都要合并到 master
- 标签（Tag）
标签是用于标记特定的点或提交的历史，通常会用来标记公布版本的名称或版本号（如：publish/0.0.1），尽管标签看起来有点像分支，但打上标签的提交是固定的，不能随便的改变，参见上图中的 1.0 / 2.0 / 3.0
- HEAD
HEAD 指向的就是以后分支的最新提交图片
以上概念理解的差不多，那就能够持续往下看。
Git 命令
- 创立仓库
克隆一个已创立的仓库：
# 通过 SSH
$ git clone ssh://user@domain.com/repo.git
#通过 HTTP
$ git clone http://domain.com/user/repo.git创立一个新的本地仓库：
$ git init-
增加批改
增加批改到暂存区：# 把指定文件增加到暂存区 $ git add xxx # 把以后所有批改增加到暂存区 $ git add . # 把所有批改增加到暂存区 $ git add -A提交批改到本地仓库：
# 提交本地的所有批改 $ git commit -a # 提交之前已标记的变动 $ git commit # 附加音讯提交 $ git commit -m 'commit message' - 储备
有时，咱们须要在同一个我的项目的不同分支上工作。当须要切换分支时，偏偏本地的工作还没有实现，此时，提交批改显得不谨严，然而不提交代码又无奈切换分支。这时，你能够应用 git stash 将本地的批改内容作为草稿储备起来。
官网称之为储备，但我集体更喜爱称之为存草稿。
# 1. 将批改作为以后分支的草稿保留
$ git stash
# 2. 查看草稿列表
$ git stash list
stash@{0}: WIP on master: 6fae349 :memo: Writing docs.
# 3.1 删除草稿
$ git stash drop stash@{0}
# 3.2 读取草稿
$ git stash apply stash@{0}- 撤销批改
撤销本地批改：
# 移除缓存区的所有文件（i.e. 撤销上次 git add）$ git reset HEAD
# 将 HEAD 重置到上一次提交的版本，并将之后的批改标记为未增加到缓存区的批改
$ git reset <commit>
# 将 HEAD 重置到上一次提交的版本，并保留未提交的本地批改
$ git reset --keep <commit>
# 放弃工作目录下的所有批改
$ git reset --hard HEAD
# 将 HEAD 重置到指定的版本，并摈弃该版本之后的所有批改
$ git reset --hard <commit-hash>
# 用远端分支强制笼罩本地分支
$ git reset --hard <remote/branch> e.g., upstream/master, origin/my-feature
# 放弃某个文件的所有本地批改
$ git checkout HEAD <file>删除增加.gitignore 文件前谬误提交的文件：
$ git rm -r --cached .
$ git add .
$ git commit -m "remove xyz file"撤销近程批改（创立一个新的提交，并回滚到指定版本）：
$ git revert <commit-hash>彻底删除指定版本：
# 执行上面命令后，commit-hash 提交后的记录都会被彻底删除，应用需谨慎
$ git reset --hard <commit-hash>
$ git push -f- 更新与推送
更新：
# 下载近程端版本，但不合并到 HEAD 中
$ git fetch <remote>
# 将近程端版本合并到本地版本中
$ git pull origin master
# 以 rebase 形式将远端分支与本地合并
$ git pull --rebase <remote> <branch>推送：
# 将本地版本推送到近程端
$ git push remote <remote> <branch>
# 删除近程端分支
$ git push <remote> :<branch> (since Git v1.5.0)
$ git push <remote> --delete <branch> (since Git v1.7.0)
# 公布标签
$ git push --tags- 查看信息
显示工作门路下已批改的文件：
$ git status显示与上次提交版本文件的不同：
$ git diff显示提交历史：
# 从最新提交开始，显示所有的提交记录（显示 hash，作者信息，提交的题目和工夫）$ git log
# 显示某个用户的所有提交
$ git log --author="username"
# 显示某个文件的所有批改
$ git log -p <file>-
显示搜寻内容：
# 从当前目录的所有文件中查找文本内容 $ git grep "Hello" # 在某一版本中搜寻文本 $ git grep "Hello" v2.5 - 分支
增删查分支：
# 列出所有的分支
$ git branch
# 列出所有的远端分支
$ git branch -r
# 基于以后分支创立新分支
$ git branch <new-branch>
# 基于近程分支创立新的可追溯的分支
$ git branch --track <new-branch> <remote-branch>
# 删除本地分支
$ git branch -d <branch>
# 强制删除本地分支，将会失落未合并的批改
$ git branch -D <branch>切换分支：
# 切换分支
$ git checkout <branch>
# 创立并切换到新分支
$ git checkout -b <branch>标签
# 给以后版本打标签
$ git tag <tag-name>
# 给以后版本打标签并附加音讯
$ git tag -a <tag-name>合并与重置
merge 与 rebase 尽管是 git 罕用性能，然而强烈建议不要应用 git 命令来实现这项工作。
因为如果呈现代码抵触，在没有代码比对工具的状况下，切实太艰巨了。
你能够思考应用各种 Git GUI 工具。
合并：
# 将分支合并到以后 HEAD 中
$ git merge <branch>重置：
# 将以后 HEAD 版本重置到分支中，请勿重置已公布的提交
$ git rebase <branch>更多命令参考：三年 Git 应用心得 & 常见问题整顿
Git 分支开发
Git 是目前最风行的源代码管理工具。为标准开发，放弃代码提交记录以及 git 分支构造清晰，不便后续保护，现标准 git 的相干操作。
分支命名
1、master 分支
master 为主分支，也是用于部署生产环境的分支，确保 master 分支稳定性，master 分支个别由 develop 以及 hotfix 分支合并，任何工夫都不能间接批改代码
2、develop 分支
develop 为开发分支，始终保持最新实现以及 bug 修复后的代码，个别开发的新性能时，feature 分支都是基于 develop 分支下创立的。
- feature 分支
开发新性能时，以 develop 为根底创立 feature 分支。
分支命名: feature/ 结尾的为个性分支，命名规定: feature/user_module、feature/cart_module
- release 分支
release 为预上线分支，公布提测阶段，会 release 分支代码为基准提测。当有一组 feature 开发实现，首先会合并到 develop 分支，进入提测时会创立 release 分支。如果测试过程中若存在 bug 须要修复，则间接由开发者在 release 分支修复并提交。当测试实现之后，合并 release 分支到 master 和 develop 分支，此时 master 为最新代码，用作上线。
- hotfix 分支
分支命名: hotfix/ 结尾的为修复分支，它的命名规定与 feature 分支相似。线上呈现紧急问题时，须要及时修复，以 master 分支为基线，创立 hotfix 分支，修复实现后，须要合并到 master 分支和 develop 分支
更多开发标准请参阅：全网最全的 Git 分支开发标准手册 | 把握这 10 条标准，轻松搞定 Git！
Git 这些高级用法，喜爱就拿去用！
Git 提交标准
为什么须要标准？
无规矩不成方圆，编程也一样。
如果你有一个我的项目，从始至终都是本人写，那么你想怎么写都能够，没有人能够干涉你。可是如果在团队合作中，大家都张扬共性，那么代码将会是一团糟，好好的我的项目就被糟践了。不论是开发还是日后保护，都将是劫难。
这时候，有人提出了何不统一标准，大家都依照这个规范来。于是 ESLint，JSHint 等代码工具如雨后春笋般涌现，成为了我的项目构建的必备良品。
Git Commit 标准可能并没有那么夸大，但如果你在版本回退的时候看到一大段糟心的 Commit，恐怕会懊恼不已吧。所以，严格遵守标准，利人利己。
具体请参阅：你可能会疏忽的 Git 提交标准
Git 应用技巧
只有在遇到问题的时候，才领会到技巧带来的益处！
常见企业工作流程
次要介绍，企业中罕用的 Git 工作流程！
- Git Flow
- 骨干分支
- 稳固分支
- 开发分支
- 补丁分支
- 批改分支
Github Flow
- 创立分支
- 增加提交
- 提交 PR 申请
- 探讨和评估代码
- 部署检测
- 合并代码
Gitlab Flow
- 带生产分支
- 带环境分支
- 带公布分支
日常应用最佳实际
总结日常工作中应该遵循的 Git 应用形式和办法！
- 应用命令行代替图形化界面
- 应用命令行来操作，简洁且效率高
- 提交应该尽可能的表述提交批改内容
- 辨别 subject 和 body 内容，应用空行隔开
- subject 个别不超过 50 个字符
- body 每一行的长度管制在 72 个字符
- subject 结尾不须要应用句号或者点号结尾
- body 用来具体解释此次提交具体做了什么
- 应用 .gitignore 文件来排除无用文件
- 可应用模板文件，而后依据我的项目理论进行批改
- 基于分支或 fork 的开发模式
- 不要间接在骨干分支下面进行开发
- 在新建的分支上进行性能的开发和问题的修复
- 应用 release 分支和 tag 标记进行版本治理
- 应用 release 分支公布代码和版本保护(release/1.32)
- 应用 tag 来标记版本(A- 大 feature 性能.B- 小 feature 性能.C- 只修 bug)
常用命令汇总整顿
日常应用只有记住 6 个命令就能够了。
无论是开发、运维，还是测试，大家都晓得 Git 在日常工作中的位置。所以，也是大家的必学、必备技能之一。
然而呢，民工哥，也常常在后盾看到读者说，命令太多了不好记啊，工夫长了不必又遗记了等等的吐槽。是啊，要学一门技术真难，何况当初技术更新、迭代这么快 …..
所以，对于学习 Git 这门技术，要是有一个一看就懂，一学就会的入门材料就好了。前不久，国外的一位小姐姐写了一篇这样的文章《CS Visualized: Useful Git Commands》。作者是来自英属哥伦比亚的小姐姐 Lydia Hallie，在这篇文章外面，她通过活泼形象的动画，以更加直观的形式，向开发者展现 Git 命令中的 merge、rebase、reset、revert、cherry-pick 等罕用骚操作的具体原理。小姐姐用动画图解 Git 命令，一看就懂！
# 工作区 -> 暂存区
$ git add <file/dir>
# 暂存区 -> 本地仓库
$ git commit -m "some info"
# 本地仓库 -> 近程仓库
$ git push origin master # 本地 master 分支推送到近程 origin 仓库 # 工作区 <- 暂存区
$ git checkout -- <file> # 暂存区文件内容笼罩工作区文件内容
# 暂存区 <- 本地仓库
$ git reset HEAD <file> # 本地仓库文件内容笼罩暂存区文件内容
# 本地仓库 <- 近程仓库
$ git clone <git_url> # 克隆近程仓库
$ git fetch upstream master # 拉取近程代码到本地但不利用在以后分支
$ git pull upstream master # 拉取近程代码到本地但利用在以后分支
$ git pull --rebase upstream master # 如果平时应用 rebase 合并代码则加上# 工作区 <- 本地仓库
$ git reset <commit> # 本地仓库笼罩到工作区(保留回退文件内容批改)
$ git reset --mixed <commit> # 本地仓库笼罩到工作区(保留回退文件内容批改)
$ git reset --soft <commit> # 本地仓库笼罩到工作区(保留批改并加到暂存区)
$ git reset --hard <commit> # 本地仓库笼罩到工作区(不保留批改间接删除掉)更多对于 Git 的应用技巧介绍请查阅：学会这 11 条，你离 Git 大神就不远了！