git简单教程：
此教程借鉴了互联网上很多人的分享，在次首先感谢你们的奉献。
开篇：git的由来.
Linus（林纳斯）是一个伟大的黑客，曾就职于美国加州硅谷的一家科技公司，是Linux系统的创始人，坚持开源精神，竞争对手是微软。
1969年林纳斯出生于芬兰，1982年林纳斯的爷爷童奎(芬兰赫尔辛基大学的统计学教授)，为了在家可以完成工作买了一个早期的电脑，但问题是习惯了用纸和笔的童奎很不习惯敲键盘，于是他把目光转向了11岁的外孙林纳斯，童奎在纸上写好代码，有童奎输入进电脑。于是放学回家帮外公输程序成为了林纳斯的“家庭作业”，很快他敲键盘的熟练度超过了外公。久而久之，他觉得仅仅帮外公输入程序有点无聊，开始试着自己编程，并从此对变成上瘾。热爱变成的林纳斯是个不折不扣的直男，上中学时虽然数学成绩超好却不解风情。一直没明白找他补数学的女孩子并让他帮自己养猫是什么意思。
19岁是他考入了爷爷曾任教的大学，选择了计算机专业，那是计算机专业是个冷门专业。当时他深爱的操作系统叫Unix，当时的操作系统功能简单，bug丛生，林纳斯决心编写一个自己的操作系统，他在赫尔辛基一家经营电脑的夫妻店，花了3500美元DIY了一台外观平淡无奇但是性能彪悍的电脑，他付了1200美元，剩下的需要再三年内还清。
1991年9月，正在上大二的林纳斯将Linux系统0.01版本发布，源代码超过1000万行。Linux系统一出现，深受全球黑客的喜爱，经过他们的共同努力，1994年3月14日Linux系统1.0版本在赫尔辛基大学发布。
相比于当时如日中天的Windows，Linux完全免费，并具备图形界面。 鲜明的特色赋予了Linux强大的生命力，使它在Windows开始独霸全球操作系统时，仍能撕开一条口子。
时至今日：
80%以上的只能手机，均使用基于Linux内核的Android系统。
75%的云计算在Linux系统上运行。
没有Linux系统就没有现在的Google搜索，淘宝购物，微信，QQ聊天等。
就像所有的美国名人都来此华尔街或者硅谷一样。1996年底，林纳斯收到硅谷一家在美国并不知名的公司全美达的offer后，离开芬兰飞赴纽约。在硅谷工作期间不仅拒绝了乔布斯的邀约(因为乔布斯让他放弃Linux)，也经常和微软打口水仗。
在git之前有很多的版本控制工具例如CVS，和SNV，但林纳斯并不喜欢集中式的版本控制工具。虽然那时有些付费的版本控制工具很好用，但不符合林纳斯的开源精神(就像玛丽·居里一样发现了镭这种元素但是并没有当做自己赚钱的工具而是把发现公布与众，简单的说就是免费给别人用)，一家出售版本控制系统的公司（BitKeeper）找到了林纳斯授权Linux的开发者可以免费使用，这一消息极大的振奋了Linux的开发者。要知道再次之前世界各地的开发者是使用邮件将代码发给林纳斯，再由林纳斯手动合并。
但Linux社区牛人聚集，一些梁山好汉视图破解这一软件，引起了BitKeeper公司的强烈不满，曾威胁要撤销他们免费使用的权利。小弟烦了事儿，大哥主动帮抗，林纳斯并没有像BitKeeper公司道歉而是闷头花了两周的时间自己用C写了一个分布式版本控制系统，这就是GIT，尤其是2008年，GitHub网站上线了，它为开源项目提供免费存储，无数开源项目开始迁至GitHub。
起步:下载git
git下载地址：
改变git的UI样式：
找到安装git的文件夹，进去之后，右击git-bash.exe选择 以管理员身份运行 。
接着复制粘贴如下命令:
git clone https://github.com/xnng/my-git-bash.git
cd my-git-bash
git clone https://gitee.com/xnng/bash.git
cd bash
接下来，安装字体:
#这是注释：运行完下边这条命令之后，window电脑会打开两个文件夹，一个文件夹里有很多.ttf文件，另一个
#文件夹里只有一个，把仅有的这一个直接拖到另一个有很多文件的文件夹里
start c://Windows//Fonts && start %cd%/fonts
接下来安装主题:
cp .minttyrc ~ && cp git-prompt.sh /etc/profile.d
exit
做完上面的操作之后有的电脑会重启一下gitbush有的电脑把gitbush关了之后不再重启，如果电脑没有自动重启gitbash只需手动打开就可以了。
git指南北东西
创建版本库
git init
添加操作
#添加操作实际上是把文件修改添加到暂存区
#单独添加某个文件的修改
git add 文件名称
#添加所有文件的修改使用的是小写的点
git add .
提交操作
#提交更改，实际上就是把暂存区的所有内容提交到当前分支
#会提交所有添加后的文件
git commit -m"本次提交的描述"
查看当前仓库里所有文件的状态：
git status
查看一个文件修改了哪一部分：
git diff 文件名
查看提交历史：
git log
#让日志变得更漂亮
git log --pretty=oneline
回到上一个版本
#上一个是HEAD^ 回到上上一个是HEAD^^ 回退到10个版本以前HEAD~10
git reset --hard HEAD^
回到某个特定的版本
git reset --hard 版本号
查看所有使用过的命令历史(日志)
git reflog
工作区
git仓库所在的目录就是工作区
版本库
.git文件夹就是当前这个git仓库的版本库，这个不是工作区；
里边存了很多东西，其中最重要的是
stage【暂存区】、git自动创建的第一个分支master【主分支】、以及指向master【主分支】的指针HEAD。
修改了一部分把它添加到了暂存区，但是又对文件进行了一波修改
#第一次修改
git add .
#第二次修改，继续添加
git add .
#统一提交
git commit -m"描述"
撤销修改
#让文件回到最近一次添加或提交时的样子
git restore 文件名
#撤销单个
git restore --staged 文件名
#撤销多个
git restore --staged .
删除文件
#手动删除一个文件之后，git版本库里依然是有这个文件的，如果要把git版本库里的文件也删除掉，使用git rm命令。比如说我们现在手动删除了一个叫做demo1.html的文件，接着
git rm demo1.html
#从版本库里删除之后要再进行一次提交
git commit -m"描述"
远程仓库
文中的克隆指的是下载：
git之所以叫做分布式版本控制系统，同一个git仓库，可以分布到不同的电脑上，那么怎么分布呢？最早，肯定只有一台机器有这个版本库，别人可以直接把你的这个版本库复制到自己的电脑里，复制完成之后，每个人都有了一个一样的版本库，这些分布在不同人不同电脑上的版本库并没有主次之分。这样即使某个人的电脑坏了文件丢失了，也可以再克隆一遍。假如说我们有一个git仓库，别人需要克隆，我们不知道有多少个人要克隆，也不知道他们什么时候来克隆这个版本库，因此我们就必须保持电脑24小时开机，而在实际开发中我们一般会把这个git仓库放在一台服务器上，这样无论何时何地只要有网络任何人都可以克隆这个仓库。而
github就为我们免费提供了一个可以存储git仓库的服务器，我们只需要注册一个github的账号就可以了。怎么注册呢：
注册github账号
github网址： https://github.com/
github是一个免费的代码托管平台，用户范围遍布全球，我们放在上边的项目别人可以查看和克隆，别人放在上边的项目我们也可以查看和克隆，这样即便是离我们很遥远的牛人，我们也可以把他们公开的项目下载下来玩弄一番]。
接着创建SSH Key
#我们把项目放到github上托管后，其他人也可以看到和下载，为了防止别人修改我们在远程仓库里的代码，github使用一种加密认证，只有认证通过才可以修改远程仓库里的代码。那别人下载我们的代码到自己的电脑上之后可不可以在他的电脑上修改我们的代码呢？这个当然可以，我们无法控制，我们能做的是不让他改我们远程仓库里的代码
ssh-keygen -t rsa -C "你的邮箱地址"
输入完成之后不管他提示什么都一路回车，知道不能回车为止，接着把我们生成的SSH Key添加到我们自己的github账号里：
#首先你要知道自己的sshkey是什么
cat ~/.ssh/id_rsa.pub
把返回的一堆密码复制一下，填在自己github的设置里(这个密码可以随意给别人看，除非你做的是机密工作，那你不能透露给别人)。
添加上去之后我们现在就可以去修改自己账号里远程仓库里的代码了，但是我们得先有个仓库，现在我们在github上创建一个远程仓库。
接着我们找到本地的git仓库，然后把本地的仓库和远程的仓库关联起来：
#在本地
git remote add origin 远程仓库的地址
现在我们把两个仓库关联了起来，但是远程仓库里并没有我们本地仓库的代码，我们需要把本地的代码推送到远程:
#在本地
git push origin master
推送完成之后，我们会发现远程里的代码和我们本地的代码一模一样。从现在开始，只要你本地修改代码并提交之后，就可以推送到远程仓库来更新远程仓库里的内容。我们刚才所说的别人无法修改你远程仓库里的代码指的就是他不能把在他本地上修改的部分推到你的远程仓库。
刚才我们说的是如何本地仓库关联远程仓库接下来我们来看看如何把远程仓库上看到的代码克隆到本地：
git clone 仓库地址
报错：
git入门下
之前我们讲到使用git add .可以把工作区的修改提交到stage：暂存区，之后再通过git commit -m"描述"把代码提交到分支上，如此一个链路便形成了一个版本。
在上一节课里我们只知道有分支这个东西，代码被推倒分支上就可以形成一个新的版本，并返回一个版本号，但分支是什么呢？我们好像从来没有主动去创建过分支，那么他是从哪里来的呢？这节课我们来揭开分支的迷雾，完成多人开发的需求。
我们在使用git init创建一个git仓库时，git就为我们自动创建了一个叫做master的分支（master分支是主分支）。
创建分支：
git branch 分支名称
切换分支：
git switch 分支名称
以上两部操作可以进行合并：
#这行命令表示的是创建一个分支并切换到这个分支
git switch -c 分支名称
查看分支：
#查看一共有多少个分支和现在在哪一个分支上，当前分支的前边有一个*
git branch
如果当前分支是a，此时你创建了一个b分支，那么b分支里的代码将会和a分支一模一样，例：
#假设现在在master(主)分支上
git switch -c dev
#此时我们在master的基础上创建了一个dev分支，并切换到了dev分支如果对比代码我们将发现，两个分支上的代码一模一样
在切换出的dev分支上完成开发后，把代码提交到dev分支：
git add .
git commit -m"版本信息"
代码提交到dev分支后，此时master分支上并没有最新的代码，这是我们需要把dev分支上的代码合并到master分支上，合并分支使用命令：
git merge 分支名称
删除分支：
git branch -d 分支名称
其实不是每一次合并分支的时候都是一帆风顺的，比如我们现在需要修改一个bug，我们从master分支上切了一个新的分支dev，我们在dev分支上完成修改后进行提交，切回master分支，对master分支也做了修改，修改之后提交，接着我们去合并dev分支上的代码，发现合并失败。在这种情况下git无法对两个分支进行合并，只能尝试把各自的修改合并起来，这种合会出现冲突，我们需要手动去解决冲突。解决完冲突之后:
#手动解决冲突之后，再master分支上：
git add .
git commit -m"版本信息"
#接着再删除dev分支就可以了。
git switch dev
git branch -d dev
而在实际开发中，master分支应该是非常稳定的，也就是仅用来发布最新版本，平时不能在上面干活。
而合并分支我们有两种方式：
git merge 分支名称
#如果用git merge来合并的话我们是查看不到分支的合并历史的，因为 git merge是快进模式。
#除了git merge之外还有一种普通合并的模式，使用命令：
git merge --no-ff -m"版本信息" 分支名称
#上边这条命令为什么要加-m参数呢？因为普通合并模式下，git就会在merge时生成一个新的提交，这样，就可以从分支历史上查看的到。而使用git merge是查看不到合并的历史的，那我们如何查看分支历史呢？使用：
git log --graph --pretty=oneline --abbrev-commit
分别使用两种不同的合并方式合并分支时，我们打印出来的分支历史是不一样的。
在实际开发中，bug就像家常便饭一样。有了bug就需要修复，在使用git的时候，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
加入你现在正在开发一个新功能，突然接到一个紧急任务，让你修复一个代号为101的bug，很自然得，你想创建一个分支issue-101来修复它，但是你开发新功能的代码还没有提交，并不是你不想提交，而是工作只进行到一半，还没法提交，幸好git还提供了一个临时存储功能，可以帮你把没有提交的代码临时藏起来，等需要的时候再拿给你：
#使用git stash命令可以把之前写的代码暂时隐藏起来
git stash
那么修复完bug之后我如何把隐藏起来的代码再回复回来呢？
#查看被隐藏起来的代码
git stash list
#恢复代码使用
git stash pop
这是针对单次的隐藏，如果针对多次隐藏呢？使用：
git stash apply stash@{}
#接着删除某个隐藏
git stash drop stash@{}
#git stash pop可以同时完成这两步但是不适合多个隐藏
刚刚我们在master分支上修改了一个bug，而我们现在开发新功能的分支就是从master上切换出来的，那么也就是说master分支上的bug现在也存在于开发新功能的分支上，为了避免重复操作，我们可以使用:
#这条命令只会把修复master分支bug的代码合并过来
git cherry-pick 版本号(这里的版本号指的是刚修复master分支bug后提交的版本号)//智能
在软件开发中，总是有做不完的新功能，在开发新功能的时候必定要取修改原来的代码，这样如果最后遇到bug整个项目就game over了，所以每添加一个新功能，最好创建一个新的分支，开发成功后合并再删除新分支就可以了。但是有的产品经理太傻比了，真他吗的傻比，跟你说开发一个新功能，功能开发完了他又说要把这个新功能给剪掉，开发之前脑子让门挤了吗？不过还好我们并没有把新功能分支上的代码合并到主分支上，那么我们这次使用：
git branch -d 分支名称
#这是git给我们报错说这个分支的代码提交后没有合并，因此我们不能删除，不过我们可以强制删除
git branch -D 分支名称
我们在向远程仓库推代码的时候使用的是：
git push origin 分支名称
可是问题来了，我们和其他小伙伴都在开发，分别开发不同的功能，这样不同的人往一个仓库的同一个分支推送东西就产生一种情况，就是我们本地的代码和远程仓库里的代码不同步，如果你的小伙伴比你推送的时间早，那么你再推的时候就推不上去了，因为你你小伙伴最新提交和你视图推送的提交有冲突，解决办法很简单：
#使用git pull拉去最新的代码，然后在本地合并解决冲突后再推送，
git pull origin 分支名称
#如果拉去失败，说明本地的这个分支和远程的这个分支没有建立连接，那么我们要手动的建立这个链接
git branch --set-upstream-to=origin 远程分支名称 本地分支名称
#接着再使用 git pull就可以了
git pull origin 远程分支名称
#我们从远程分支拉去最新代码后如果产生冲突，则需要手动解决冲突，冲突解决之后需要提交再推
git commit -m"提交信息"
git push origin 分支名称
所以在多人协作的时候流程大概是这样的：
- 视图把本地的代码推送到远程分支上
git push origin 分支名称，结果推送失败。 - 接着从远程分支拉去代码，
git pull origin 分支名称，如果有冲突手动合并冲突。 - 使用
git push origin 分支名称。 - 所以每次提交前先
git pull一下是个好习惯。
标签：
加入你的leader（领导）问你要某个版本的代码，发给你了一串类似于`a10996b`的版本号，那么接下来你可能要进行的操作是：
git log
#结果返回了一大推的版本号，要找到这个叫做a10996b可能头都找破了也没找到，这时要是给每次提交都打一个简单的标签，必须：v1.0，那么你的boss可能对你说的是，小王，把那个0.9版本的代码发我一下，那么你只要找到提交时被标记了v0.9的版本给他就可以了，这个操作在git中可不可以实现呢？当然是可以的，怎么做呢？
#先切换到指定分支
git switch 分支名称
#接着
git tag v1.0
#这样就ok了，那怎么查看有多少个版本呢？使用：
git tag
#上边这条命令会返回所有的版本号
#那如果上次的版本我忘记打标签了呢？没关系，先使用 git log查找到历史
git log --pretty=oneline --abbrev-commit
#找到版本号之后
git tag v0.9 版本号
#如果标签打错了，也可以删除
git tag -d v1.0
