标签：修复bug 演示 change stat 工作区 git分支 问题 存在 pretty
git简介
- git的产生历史
- git的特点
- 集中式分布式版本控制的区别
- git的安装配置
命令: git init git add <name>
git commit -m '版本描述' git reset --hard HEAD^
git reset --hard <版本号的部分> git log
git log --pretty=oneline git reflog git status 查看当前工作区的状态 git checkout -- <name>
git reset HEAD <name> git diff HEAD HEAD^ -- name
对比两个版本之间相同文件的差别
git diff HEAD --<name>
对比最新版本和工作区相同文件的差别 rm name
git rm name git branch
查看当前所有的分支。 * 号后面接的那个分支就是目前正在使用的分支
git branch <name>
创建新的分支
git checkout <name>
切换分支
git checkout -b <name>
创建并切换新的分支
git merge <name>
快速 合并name分支到当前主分支
值得注意的是前面讲的快速合并(Fast Forword)是
直接将 master 直接移到当前分支指的提交的位置。是git合并一般默认快速合并
有些分支的合并不能够用快速合并。需要注意。
git branch -d <name>
删除某分支 不同分支修改同一文件并都在各自的分支上提交了版本 在分支上提交完版本后，回到主分支上直接进行合并不做任何的修改 git merge --no-ff -m'版本描述' <分支>
--no-f 的意思是no fast forword git stash 保护现场
git stash list 产看保护现场在哪儿
git stash pop 恢复现场gti的产生历史
很多人都知道，Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。
Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？
事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！
你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。
不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。
安定团结的大好局面在2005年就被打破了，原因是Linux社区牛人聚集，不免沾染了一些梁山好汉的江 湖习气。开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个），被BitMover公司发现了（监控工作做得不错！），于是BitMover公司怒了，要收回Linux社区的免费使用权。
Linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。实际情况是这样的：
Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？大家可以体会一下。
Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。
历史就是这么偶然，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费而超级好用的Git了。分布式：
Git的分布式版本控制系统。
关于分布式和集中式见 分布式和集中式区别
同一个git仓库可以布置到不同的机器上，首先找一台电脑充当服务器的角色，24小时开机，其他人从这个“服务器”仓库中将代码克隆一份到自己的电脑上，修改完成后，再将代码提交到仓库中。也可以从仓库中提取别人的修改。可以自己搭建一个服务器，也可以使用现成的GitHub网站充当这个服务器的角色。
集中式：
先说集中式版本控制系统。简单的说就是，版本库是集中的存放于中央服务器的。干活的时候，先要去中央服务器里领取最新的版本，然后在开始干活。干完活在将自己的版本上传到中央服务器。
就好比要改一本书，先要从图书馆里将书籍借阅出来，然后改完了之后，在将图书归还给图书馆。然后别人看到的就是最新的版本了。
缺点:
缺点就是，一但没有网或者网络不好的话，自己写的东西就很难得传上去。别人也不能及时的看到。简单的说就是没有网就不能使用。
分布式：
分布式版本控制系统。分布式版本系统没有绝对的所谓中央服务器，每个人的电脑上都有一个版本库，使用的时候就不需要进行联网了。直接自己进行修改就行。既然每个人的电脑上都有一个版本库，那么多个人如何进行写作呢，只需要把你修改的和同事修改的进行交换就行。
比如说你修改了A文件，你的一个同事也修改了A文件。这个时候只要把自己修改的部分推给对方，对方就能够看到你的修改。
和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。
在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。
---
最根本的区别：
集中式和分布式最根本的区别就是：
分布式每个人的电脑上都可以直接拷贝完整的代码版本。而集中式只能拷贝自己需要的。
分布式的服务器挂掉之后，不会影响工作。而集中式的服务器挂掉之后，根本就没法进行工作。
当然，Git的优势不单是不必联网这么简单，后面我们还会看到Git极其强大的分支管理，把SVN等远远 抛在了后面。
CVS作为最早的开源而且免费的集中式版本控制系统，直到现在还有不少人在用。由于CVS自身设计的问题，会造成提交文件不完整，版本库莫名其妙损坏的情况。同样是开源而且免费的SVN修正了CVS的一些稳定性问题，是目前用得最多的集中式版本库控制系统。
除了免费的外，还有收费的集中式版本控制系统，比如IBM的ClearCase（以前是Rational公司的，被IBM收购了），特点是安装比Windows还大，运行比蜗牛还慢，能用ClearCase的一般是世界500强，他们有个共同的特点是财大气粗，或者人傻钱多。
微软自己也有一个集中式版本控制系统叫VSS，集成在Visual Studio中。由于其反人类的设计，连微软自己都不好意思用了。
分布式版本控制系统除了Git以及促使Git诞生的BitKeeper外，还有类似Git的Mercurial和Bazaar等。这些分布式版本控制系统各有特点，但最快、最简单也最流行的依然是Git！Git最先开始只能够在linux和unix上面跑，但是后来慢慢的就迁移到了Windows和max上面了。
返回目录(返回总的目录)
首先：
先输入命令 git 看看电脑有没有安装git
如果和下图一样，出现了一堆使用的命令，说明电脑是安装了Git的。
如果和下面一样，出现了not installed 表明还没有进行安装
$ git
The program 'git' is currently not installed. You can install it by typing:
sudo apt-get install git有些linux的版本很友好的提示了你，如何进行安装。
如果是Ubuntu或者Debian的话直接输入
sudo apt-get install git
就可以安装。非常的简单和实用
如果是其他的linux版本的，如cent，Redhat等则直接使用源码进行安装
在git官网上面下载源码，然后解压。然后依次输入命令
./config
make
sudo make install
这几个命令安装就好
注意：
如果是老一点的Debian或Ubuntu Linux。就要把命令改为
sudo apt-get install git-core
因为以前有个软件也叫GIT（GNU Interactive Tools），结果Git就只能叫git-core了。
后来由于Git名气实在太大，后来就把GNU Interactive Tools改成gnuit，git-core正式改为git。
不过一般大家基本上很少用到老一点的linux版本
如果是在Windows环境下面安装Git，直接在 官网下载，然后按照步骤一步一步的安装即可。
安装完成后，在开始菜单里找到“Git”->“Git Bash”，蹦出一个类似命令行窗口的东西，就说明Git安装成功！
在安装完成后，还需要设置用户的姓名和邮箱地址。
输入下面的命令：
$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。
注意：
git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。
如果你正在使用Mac做开发，有两种安装Git的方法。
一是安装homebrew，然后通过homebrew安装Git，具体方法请参考homebrew的文档：http://brew.sh/
第二种方法更简单，也是推荐的方法，就是直接从AppStore安装Xcode.
Xcode集成了Git，不过默认没有安装，你需要运行Xcode，选择菜单“Xcode”->“Preferences”.
在弹出窗口中找到“Downloads”，选择“Command Line Tools”，点“Install”就可以完成安装了。
Xcode是Apple官方IDE，功能非常强大，是开发Mac和iOS App的必选装备，而且是免费的！
先新建一个新的目录，然后在目录里面创建版本库。
命令：git init
可以看到在新建的目录(git_text)下面有一个隐藏的目录.git 。这就是git的版本库目录(简称为仓库)。
Git就是通过这个目录对此项目下的所有的代码，项目进行管理的。
在原有的目录(git_text)下，任意创建一个文件，这里我创建的是 (helloword.py) 然后保存就行。
版本创建的命令：
git add helloword.py #这是添加文件的命令
git commit -m "版本描述" #这是创建版本号的命令截图演示: 
查看版本记录的命令：
git log
查看详细的版本记录
git log --pretty=oneline
查看简略的版本信息
commit 后面接的才是真正的版本信息，也是版本序列号。相当于人的身份证一样。
而下面的 hello word 版本一 只是这个的描述信息。描述这个版本的。
简略的版本记录的查询只有版本号和版本描述
版本从上往下回退(如2.0到1.0)：
版本回退的意思就是，回到之前的那个版本。在项目的开发中，可能开发到4.0版本的时候又觉得之前的3.0版本比较好。就又去用之前的3.0版本。
这就是Git的一大利器的地方。版本控制，能够找回之前的历史版本，并且使用历史版本。
可以看到在原来的代码里添加了部分后，又重新创建了一个新的版本。然后查看版本记录后，可以看到有两个版本的。
如果要使用之前得版本一，可以使用版本退回命令：
git reset --hard HEAD^
#这里的HEAD是指向目前位置的指针。
如果HEAD是指向10.0的版本的话，那么
(第一种表示方法)： （第二种表示方法):
HEAD^就是指向9.0 HEAD~1 就是指向9.0
HEAD^^就是指向8.0 HEAD~4 就是指向6.0
HEAD^^^就是指向7.0 HEAD~100 就是指向前100个版本
使用了命令后看到目前位于版本一的位置，使用git log 命令进行查看也是位于版本一。
然后打开版本里面的内容也是发现，内容还是版本一的一句话，而不是版本二得函数。
原理：
HEAD就是指向当前位置的指针。HEAD^表示的就是将指针进行下移一位，然后指向下面的一个版本。版本2实在版本1的基础上进行的，是直接打开进行写的，而不是将代码整个的复制一份，然后再写在进行保存的。
从下向上回退(1.0到2.0)
命令：
git reset --hard 版本号
注意是版本号，而不是commit时候的版本描述。
复制版本号得时候，不需要将全部复制下来，只需要复制前面得几个数字就行截图：
可以看到版本一和版本02都回来了。而且里面的文件也回来了。
查看历史操作记录的作用在于，当处于1.0版本的时候，万一突然退出了git
在进去的时候位于版本1.0，想要回到版本3.0或者更高的时候，不知道版本号就无法操作。
而这个查看历史操作记录可以看到所有的操作，也能够看到版本号。
命令：
git reflog截图:
最前面的就是版本号的前几位。可以到版本号的回退的操作。
返回目录(返回总的目录)
##### 工作区
说明:
工作区的概念比较简单。就是工作的目录所在的位置就是工作区。
如我们之前创建的git_text就是一个工作区。
说明：
工作区里有一个隐藏目录 .git
这个不是工作区而是git的版本库。
git的版本库里存了很多的东西，其中最为重要的就是称为stage(或者叫index)的缓存区
还有为我们创建的 第一个分支master 以及 指向master的指针 HEAD
解释:
在前面我们创建版本的时候使用的命令：
git add
git commit -m '版本描述'由图可以看到在工作区书写的代码
需要通过两步进行提交：
第一步使用 git add 把文件添加进去，实际上就是把文件修改添加到暂存区。
第二步使用 git commit 提交更改，实际上就是把当前暂存区所有的内容提交到当前的分支。
注意:
并不是每一次添加都需要立即使用commit进行提交，可以先将多个文件放在缓存区里进行缓存
然后在一次性进行提交。
命令
git status #查看当前工作区的状态
分析:
可以看到的是
工作区里面的文件记录hello.py 刚刚修改完的。
huao.py 刚新建的，但是由于没有add添加到缓存区所以显示的是尚未加入提交，未跟踪的文件。
添加完成后再将所有的文件同一进行提交即可
分析:
当所有的提交完成后，下次查看工作区的状态会发现工作区变成了干净的工作区。
git 的文件修改：
它只会提交暂存区的修改来创建版本
解释:
如果有一个文件在修改完毕后添加了进了缓存区
然后在对这个文件进行修改并保存
修改完后直接用commit创建版本。
结果就是，工作区还没彻底清空，最终修改的部分也没有添加进版本里。
添加进版本里的是原来修改完毕加入发到暂存区的文件。
结果:
所以无论什么时候修改，一定要添加到暂存区，否则只会功亏一篑。
创建的版本只会用暂存区的来进行创建。没有加入进暂存区的修改都是白白浪费力气。
撤销修改有几种不同的情况。
返回目录 (返回的总的目录)
命令
git checkout -- '文件名'
解释:
对文件hello.py修改了后，产看当前得工作区得状态可以看到，命令给的已经很清楚了。
这里我们用撤销修改。
使用后查看文件，修改的部分都回来了。工作区也干净了。
都回到了之前的状态。
命令:
git reset HEAD <文件>
返回工作区后，再按照工作区的进行就行
git checkout -- <文件>参照之前的 版本退回
然后再向上面一样依次递推就行。
命令:
git diff HEAD HEAD^ -- name
对比两个版本之间相同文件的差别
git diff HEAD --<name>
对比最新版本和工作区相同文件的差别版本之间对比截图:
版本1.0里面的huao.py文件
可以看到的是文件内容就是一句话
print('你好全世界!')版本2.0里面的huao.py文件
可以看到里面有两句话
print('你好全世界!')
print(你好我叫胡澳!")两者进行比较
---a/huao.py对应的一般是两个比较文件的第一个
+++b/huao.py 对应的一般是两个比较文件的第二个
下面是比较结果:
前面既没有 + 号也没有 - 号的是两个文件所共有的
有+号或者-号的是 +或 - 文件所特有的
所以比较结果就是版本2.0比版本1.0多一句话
print('你好我叫胡澳！')
这和我们写的文件内容是相符的。将两个文件反过来进行比较： 
可以看到结果也是版本2.0比版本1.0多一句话。
结果都是一样的。
命令:
rm <文件名> # 这是使用Linux自带的命令进行删除
git rm <文件名> # 这是 git 的删除文件截图:
按照Linux的删除文件的方法就能够删除文件。(如截图)
由于删除也是在工作区里面。所以查看工作区的状态也是显示的删除文件。
如果误删:
按照暂存区文件的 撤销修改 来就行。
误删的修复也是从暂存区开始
git checkout -- <文件>
git reset HEAD <文件> 注意:
git rm <文件> 只是用于删除一个文件。
如果你的文件添加到版本库中了的话，永远不用担心会被删除。
但是要小心，因为只能回复到最新版本。你会丢失最近一次提交后你修改的内容。
特别注意:
如果仅仅只是刚刚创建的文件，从来没有添加到暂存区或者形成版本。一旦删除后。就只能够用
一些修复硬盘的工具来恢复了。前面讲的撤销恢复就不适用了。
如图:
返回目录 (返回总目录)
分支管理的概念
分支就好比做一个房子。水电和室内的装修可以同时进行，分两个不同线路进行，最后汇合将房子做成。
所以分支也就是几条可以独立运行的线路互相之间不会影响。最后可能会汇合将工作完成。
分支的应用:
分支在实际应用中还挺广泛的。比如说你要一个做一个项目，每个人完成25%的项目，但是需要两周才能够完成。第一周你只写了50%的代码，如果提交上去的话，不完整的代码会导致别人的无法正常运行。如果等到代码写完了在提交的话又可能会导代码丢失进度的风险。
但是现在有分支之后就好多了，你有了一个属于自己的分支别人看不到，别人还继续在原来的分支上进行工作。但是你在自己的分支上，想提交就提交，直到开发完毕后，在一次性将代码合并到原来的分支上。这样既安全，又不影响别人的工作。
讲解
git 把我们之前每次提交的版本串成一条时间线，这个时间线就是一个分支。
在没有创建分支之前都只有一条分支。
在git里面叫做 主分支，即 master分支
HEAD严格来说不是 指向提交，而是指向master
而master才是指向提交的。所以HEAD指向的就是当前分支。
命令:
git branch
查看当前所有的分支。 * 号后面接的那个分支就是目前正在使用的分支
git branch <name>
创建新的分支
git checkout <name>
切换分支
git checkout -b <name>
创建并切换新的分支
git merge <name>
快速 合并name分支到当前主分支
值得注意的是前面讲的快速合并(Fast Forword)是
直接将 master 直接移到当前分支指的提交的位置。是git合并一般默认快速合并
有些分支的合并不能够用快速合并。需要注意。
git branch -d <name>
删除某分支使用:
切换回master主分支
切换回master分支发现并没有之前提交的 dev版本1.0 是因为两个分支还有进行快速合并
合并dev和master分支
合并完成后可以看到出现了dev版本1.0
删除dev分支
删除分支后发现只有主分支 master 了
原因:
两个分支同时修改了同一个文件并提交了相应的版本。进行merge的时候出现冲突。需要手动进行合并，再进行提交。如图所示：
只要不是上面的条件都不会造成冲突
截图演示:
将master分支和dev分支进行合并，出现冲突
可以看到出现冲突 的文件是 hu.txt
解决方法
解决方法就是自己手工进行柔和。然后再提交。
提交版本
这样冲突就解决了。
冲突解决完了后，就可删除dev分支了
说明
通常合并分支的时候，git回自动采取Fast Forword也就是快速合并模式。
但是有些时候快速合并并不能够成功，而且合并的时候还没有出现冲突，一片和谐。
这个时候会合并之后做一次新的提交。但是这种模式下，删除分支之后，对丢掉分支的信息如图所示：
当切换到 dev 分支修改 code.txt 文件并提交版本结束后。
又回到原来的 master 分支修改 huao.txt 文件并提交了版本的时候。
这两个文件一定不是同一个文件，不然就冲突来了。
将两个分支进行合并。
框框中的是对合并后的文件进行重新描述的地方。描述完后直接退出就行。下面有提示的命令
然后将env分支删掉就行
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，
到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，
时不时地往dev分支上合并就可以了。所以，团队合作的分支看起来就像这样：
Git分支十分强大，在团队开发中应该充分应用。
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，
能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。在merge命令中讲解的很清楚，就不再进行多的赘述了
简单的说就是在 dev 分支中提交了版本后
切换回 master 版本就不再修改啥，直接合并。就默认是快速合并命令
git merge --no-ff -m '版本描述' <分支名>
命令
git stash 将工作现场存储起来，等以后恢复现场再进行工作
git stash list 用于查看刚刚存储的工作现场的位置
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了，一举两得。原因
在做开发的时候，很可能写代码写到一半，突然出了BUG要回去修复。所以就需要将工作区临时存放起来，把bug修改完成后再回来继续写代码。所以这个功能的重要性就不言而喻了。
在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。
那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？
有木有更简单的方法？
有！
同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。
为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：
$ git branch
有些聪明的童鞋会想了，既然可以在master分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么直接在dev分支上修复bug，然后在master分支上“重放”行不行？当然可以，不过你仍然需要git stash命令保存现场，才能从dev分支切换到master分支。
文本低端
标签：修复bug 演示 change stat 工作区 git分支 问题 存在 pretty
原文地址：https://www.cnblogs.com/huao990928/p/12392033.html
