Git 的诞生是一个非常有趣的故事。1991年 Linus 开源了 Linux 内核，无数 Linux 爱好者在世界各地为 Linux 编写代码，那么问题来了，这些代码该如何管理呢？起初 Linus 使用 BitKeeper(BitMover 公司的版本控制软件)管理 Linux 的核心开发，后来 BitMover 停止了对 Linux 的支持，于是 Linus 秉承自己的版本自己写的精神，花了两周时间自己用 C 写了一个分布式版本控制系统，这就是 Git。
Git 入门
传统的设计方案我们可以简单的分成两块：工作目录，远程仓库。但是作为一个目标明确的分布式版本控制系统，首先要做的就是添加一个本地仓库。接着我们选择在工作目录与远程仓库中间加一个缓冲区域，叫做暂存区。
如果还是没弄懂，那再来看看这篇精简版的吧。
无论你是前端还是后台，无论是运维还是移动端研发，GIT是逃避不了的东西，当然你说你要用SVN，那不在这次的讨论范围之内。不多说，请看下文GIT图解分析，10分钟学会git操作，当然下面的教程是为实战为主，会跟你在别的网站看到的不一样。
实战是掌握一个工具最快的方法。
什么是版本库？版本库又名仓库，英文名repository,你可以简单的理解一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改，删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻还可以将文件”还原”。
实战结束，来闯关试试学会了多少。
为保大家都能顺利通关，学到所有的知识点，接下来我会写过关攻略，详细介绍每一关的玩法。并且我不会直接给答案，而是演示整个过关的过程。
闯过这 54 关，点亮你的 Git 技能树 (五) - 完结篇
附上备忘小手册。
第一次连接远程仓库的配置
管理修改
撤销修改(没有提交的[commit])
删除文件
创建与合并分支
Bug分支管理
远程仓库的操作
下面是自己学习使用git的常用的命令，还有些使用过程中碰到问题的解决办法，现整理如下。
Git 深入理解
相信经过上面的入门以后，再对比下面的图解会更有收获和体会。
本文背景，在实际项目中使用git已有一年多，发现不少同事虽然会使用常用git指令，但并不理解每个指令对应的作用原理。今天静下心总结下git 的基本理解：代码的存在区域；本文以实际项目出发，理清使用git过程中，代码的迁徙流程。
场景： 提交了一个commit（该提交包含很多文件）， 发现有问题， 需要回滚， 将线上分支（master）回滚到上一次commit。
git 的分支是它最明显的特性， 大部分人听别人推荐使用git都会听到“git分支操作方便...”，对比其他版本控制系统git 分支操作有难以置信的轻量，创建新分支几乎瞬间完成，不同分支之间切换也非常快捷方便；本文将结合实践以及绘图归纳、总结git常见的分支操作指令以及注意事项。
终于看完了，最后再来总结回顾一下。
个人觉得git是需要认真学的，虽然是个工具但不学习很容易把自己弄糊涂，希望这篇博客可以在某些时候帮到您，让您大概理解git的工作原理并把基本命令串起来。那么下面就说一下Git重要的基本命令吧。
本文专注于支撑 Git 的图结构以及这些图的性质影响 Git 行为的方式。通过了解底层，你可以将你心中对 Git 的模型建立在事实之上，而不是基于通过积累使用经验而建立的假设上。这个更真实的模型可以让你更好的理解 Git 做了什么，正在做什么以及将要做什么。
Git 进阶
Master 是 Git 默认的主分支，版本库初始化以后，默认就是在主分支在进行开发。master分支代码最完整，最干净，用于生产环境。
主分支只用来发布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支叫做Develop。
还有一些辅助开发分支，用于应对一些特定目的的版本开发。
在讲git的reset和checkout的区别之前，不得不说说HEAD、Index、Working Directory三个区域。
git rebase因其“新手应当远离的Git黑魔法”的名号名声在外，但只要使用得当，其可以使团队开发变得无比轻松。本文将对比两个相似的命令：git rebase与git rebase来区分它们的使用场景，最终将“黑魔法”纳入自己的工作流中。
本文主要讲解下Git Rebase的基本概念用法、其内部原理以及我们在真实项目中使用Git Rebase应该遵循的原则以及为啥需要遵循这些原则。
diff是我们每天都要使用的一个功能，每次提交时，我都习惯先用git diff --cached看看这次提交更改了些什么，确定没问题，然后再git commit。git生成的diff非常直观，直观到我从来都没有去思考过diff是怎么生成的，觉得这应该是很简单的一件事，两个文件做个对比，不就行了。
本来计划本篇介绍Git分支的相关知识点与操作，但是准备的过程中发现涉及到很多内部存储原理，决定先介绍一下Git存储原理，明白了这些，有助于理解后续内容，对Git的使用也会有很大帮助。
本文讲述了如何使用 git rebase -i 及 git cherry-pick 实现代码回滚。代码回滚属于高危操作，建议慎用！
Git 高阶
深入理解学习Git工作流（git-workflow-tutorial）
工作流其实不是一个初级主题，背后的本质问题其实是有效的项目流程管理和高效的开发协同约定，不仅是Git或SVN等VCS或SCM工具的使用。
这篇指南以大家在SVN中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的分布式工作流，还介绍了如何配合使用便利的Pull Request功能，体系地讲解了各种工作流的应用。
统一的工作流程是至关重要的，不管对于哪一个行业的作业来说都一样。对于我们开发人员，工作流包含了开发时 Git 的使用规范、Repo 管理的规范、测试过程的规范、设计交互的管理规范等等。本篇文章重点说 Git 的使用规范和 repo 管理的规范。
Gitflow工作流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分，但提供了用于一个健壮的用于管理大型项目的框架。
Gitflow工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。除了使用功能分支，在做准备、维护和记录发布也使用各自的分支。当然你可以用上功能分支工作流所有的好处：Pull Requests、隔离实验性开发和更高效的协作。
本文定位于为使用GIT标准分支开发流程的开发团队新人提供一份参考指南，其中的内容都是我们公司在研发团队初创时所遵循的一些开发流程标准，经过近一年的实践，虽说还有很多不足，但是随着团队经验的丰富和人员的扩张，我会适时地更新本文，分享我们在使用GIT开发流程中遇到的问题和解决方案。
因为gitHub上的项目是公开的，不适合公司内部项目放在上面，而私人的需要收费，这绝非是我们愿意的。所以找了个跟gitHub很相似，但是又免费的gitLab。现在将搭建gitLab过程记录一下留作参考。
用 Git Subtree 在多个 Git 项目间双向同步子项目，附简明使用手册
什么时候需要 Subtree ？
1、当多个项目共用同一坨代码，而这坨代码跟着项目在快速更新的时候
2、把一部分代码迁移出去独立为一个新的 git 仓库，但又希望能够保留这部分代码的历史提交记录。
Git-WebHook 自动化部署工具 - 支持Github / GitLab / Gogs / GitOsc
Git WebHook 是一个使用 Python Flask + SQLAchemy + Celery + Redis + React 开发的用于迅速搭建并使用 WebHook 进行自动化部署和运维系统，支持：Github / GitLab / Gogs / GitOsc。
Python 使用 Tornado 框架实现 WebHook 自动部署 Git 项目
为了方便开发测试或项目部署至服务器不那么繁琐，搞一个自动部署的小轮子也是必要的。小轮子需要涉及到 Coding 项目托管平台(也可以用 Github 平台)，Linux服务器的Nginx、Python( Tornado框架 )。同时配置项目托管平台的个人私钥或项目公钥，保证 git pull 能直接拉取。
前言：本教程只面向那些个人开发者，想要自己在linux上搭建一个git中央仓库用来上传发布自己的项目。但是对于团队来说可能有更高的要求，可以使用gitlab搭建一个可视化的类似github的版本管理系统
Git 小知识
使用 "5W1H" 写出高可读的 Git Commit Message
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。