//强制删除，删除前请确认好
rm -rf 文件名 //这种方式可以强制删除文件夹，哪怕里面有文件，所以这种删除前请务必确认
==================================================================
在使用Git之前需要配置用户和邮箱，为什么要配置？因为总要告诉别人是谁修改谁提交了把，不然同事怎么知道是谁修改了呢；
//配置用户
git config --global user.name “你的用户名”
回车后，没有任何提示，那么就是配置成功，如果有错误，按照提示修改后，再设置；
//配置邮箱
git config --global user.email “你的邮箱”
回车后，没有提示错误，那么就是配置成功，如果有错误，按照提示修改后，再设置；
如果忘了设置的账号邮箱，那么通过可以通过以下命令查看，该命令可以查看所有的设置信息
git config --list
如果要查看某一项配置，比如单独查看用户名，单独查看邮箱，那么可以如下
//单独查看用户名
git config user.name
//单独查看邮箱
git config user.email
如果想查看所有的命令，可以输入
//查看所有的命令提示
git help
//单独查看某个指定的命令
//比如现在通过git help查询到了一个命令叫做commit，想了解更多commit的信息，可以如下
git help commit
有时在终端会处于编辑模式，就是不是正常的输入命令的状态，那么退出编辑模式就是输入字母q就可以了
==============================================================
使用git管理一个项目，首先你得拥有一个项目，之后通过cd命令，进入到该文件夹路径下，之后初始化管理项目的版本仓库
//初始化版本仓库
git init
之后会跳出一段提示，大致意思是在该路径下已经创建了一个版本仓库；这个版本仓库实际上就是一个文件夹，不过这个文件夹默认是隐藏的，因此如果是mac系统，按住：shift + command + . 这三个键可以查看隐藏文件夹，如果有git这个文件夹，那么就是初始化成功了，或者也可以通过命令查看这个文件夹，在该文件夹的路径下，输入
//显示该路径下所有隐藏和不隐藏的文件，文件夹
ls -la
假如，有一天，你不想再使用Git管理该项目了，怎么办？直接删除git这个文件夹就好了，具体可以直接删除，或者通过命令删除
==============================================================
Git中一共有三中状态，已修改，已暂存，已提交，当我们修改编辑，删除，新增了文件，那么此时的文件就处于已修改状态，之后我们确认了以一下文件，似乎没问题，那么就可以通过命令，将文件添加到暂存的区域，暂存区域的这些文件就处于已暂存状态，之后，再确认这些文件ok，没有问题，可以提交到本地仓库保存了，那么再通过命令，保存到本地仓库，文件一旦保存到本地仓库，那么此时git就会生成一个时间点，在这个时间点上就会有你保存的这些文件；
当一个项目中有新建文件，删除文件，或者修改文件后，输入以下命令查看
git status
输入命令后，在终端中对所有有修改的文件进行红色标记，换句话说，有红色标记的文件就是有修改的文件；
通过查看状态，发现有修改的文件，此时，就需要将有修改的文件添加入本地的版本仓库的暂存区域，可以这么理解，每一次修改，需要先将文件都放入暂存的区域，当文件在这部分区域的时候，git不会帮你记录，因为你还需要对这部分文件做进一步确认，只有确认过没有问题了，才需要确认保存到git仓库
//将指定文件添加入本地版本仓库的暂存区域
git add 具体文件名 //比如，有一个名为1.txt的文件，那么就输入 git add 1.txt
//将所有有修改的文件一次性添加到本地版本仓库的暂存区域
git add .
添加后，如果在通过git status查看文件状态，那么会发现，原本所有被标记成红色的文件，变成标记为绿色的文件，此时代表已经成功添加到暂存的区域了；
确认文件没有问题了，并且需要将当前的文件作为一个时间节点保存，以便日后可以追踪到，那么使用命令commit提交保存到本地仓库
git commit -m “注释”
git commit代表确认将文件保存，-m则是告诉git，需要为本次提交做一个备注，为什么要备注？很简单，假设你保存了20个不同的版本，并且都没有备注，那么一旦新版本出现了问题，你怎么知道该回溯到哪个版本;
快捷提交
正常情况下，如果修改了文件，那么需要先通过git add将文件添加到暂存区，之后通过git commit 将文件保存到本地仓库，实际上还有一中更快的办法
//相当于先执行了git add . 之后执行了git commit -m “修改信息”
git commit -am “修改信息”
当然我个人觉得虽然简单了一步，但是还是按git add来的比较好，因为git add还可以再确认一次有没有问题；
当文件处于已暂存状态时，突然发现文件里的内容有问题需要从暂存中将文件移除，不再将文件放入暂存了，那么执行
git rm --cached 文件名
如果这是发现需要将该文件删除，放入垃圾桶，这个项目不需要这个文件了，那么可以输入
git rm 文件名
如果文件已经被放到暂存了，那么如果使用上面的发现提示无法删除，那么这时候就要使用强制删除了
git rm -f 文件名
在多个提交之后，需要查看本地仓库有多少个记录的时候，输入
//查看本地仓库所有的版本记录
git log
之后假如本地仓库里有许多人的版本记录，那么这个时候你只需查找某一个人的，那么输入
//查找指定人员的提交记录
git log --author=“用户名”
如果仅仅需要查看提交记录，那么可以输入
git log --oneline
查看仓库的版本线图
//查看git仓库上的版本线图
git log --oneline --graph
查看仓库的所有分支的版本线图
//查看git仓库上的版本线图
git log --oneline --graph --all
正常情况下，文件修改了之后，假如需要上一次commit的版本进行对比，那么可以使用如下命令
//将当前处于已修改状态的文件和已提交的文件进行对比
git diff
这种对比，会将所有处于已修改的文件和已提交的文件进行对比，假如有3个文件修改了，那么3个文件的不同处都会标记出来；
如果，此时不小心将文件都git add过了，也就是所有的文件都被暂存了，这是git diff是不起作用的，因此需要输入
//将所有处于已暂存的文件和已提交的文件进行对比
git diff --cached
这样便可以将文件的不同处显示出来了；
有时候，文件的路径没有按规范存放，又或者项目的目录结构重新规整过了，需要移动文件到不同的路径下
//移动文件
git mv 原文件 文件路径
//比如
git mv Home.vue Home/ //将Home.vue文件移入Home文件夹
移动的时候，甚至可以改名，比如
//比如
git mv Home.vue Home/Home123.vue //将Home.vue文件移入Home文件夹同时重命名为Home123.vue
利用这个远离可以为文件快速改名，比如有时候不需要移动路径，但是原模块因为功能新增，导致名字不能代表新功能模块，需要改名，那么可以
//直接改名
git mv Home.vue Home123.vue //将Home.vue文件移入当前路径文件夹同时重命名为Home123.vue
只是利用了其移动到当前文件夹并重命名，达到了快速改名的效果；
还原文件到最后一次提交
很多时候修改了文件，发现修改了之后报了各种各样的错误，然后这些错误又解决不了，所以需要将文件恢复到最后一次提交的状态，需要如下操作
//将文件恢复到最后一次提交的状态
git checkout – 文件名
//比如，现在对Home.vue进行了修改，然后报了一堆错误，又解决不了，需要直接恢复到之前保存的状态
git checkout – src/views/Home.vue //将src/views下的Home.vue恢复到最后一次提交时的内容
注意，如果文件此时已经处于已暂存的状态，也就是已经git add过了，那么git checkout是不会生效的，如果要对其使用git checkout，那么必须先当文件移除暂存区，也就是
//移除暂存
git rm --cached 文件名
//或者这种移除暂存，这种也是移除暂存
git reset HEAD 文件名
移出暂存区后，就可以正常使用git checkout了
版本回退
假如现在提交之后，发现存储的版本错误了，甚至在某个版本之后的所有版本都有错误，那么就需要版本回退，注意，这个回退到某一个版本之后，后面所有的版本都会消失，因此这种回溯得慎重再慎重使用；
//快速回退到上个版本
git reset --hard HEAD^
//快速回退到上上个版本等等，依此类推
git reset --hard HEAD^^
如果版本很多，需要回溯到很早以前的一个版本
//回溯到很早以前的版本
git reset --hard 版本的哈希值
//比如
git reset --hard c61ebb3
后面的：c61ebb3，是指定的版本的哈希值，比如通过git log查看版本仓库之后，其中在版本之中有一个类似这个信息：commit c61ebb3031b0abd766e6830b772e3eb097c709a4；这个就是代表当前提交版本的哈希值，当然，回溯的时候不需要输入完整的哈希值，输入个前几位就可以了，比如前7位；
再次声明一下，这种回退之后不会保留回溯版本之后的所有版本，因此得慎用，如果要查看记录，那么可以
//查看回退记录
git reflog
回到旧版本
回到旧版本和版本回退有声明区别，区别就是：回到旧版本之后，在旧版本之后的版本并不会被删除，因为上一节中的版本回退，举个例子
版本回退之后
假设你的仓库里有：version 1 -> version 2 -> version 3三个版本，从version 3回到version 2之后，那么实际上version 3是会被删除的，此时你的版本库中只有：version 1 -> version 2，有时候我们不需要这样的回退，只需要将当前的版本回到某一个旧的版本；
回到旧版本之后
假设你的仓库里有：version 1 -> version 2 -> version 3三个版本，从version 3回到version 2之后，那么实际上是往当前的版本中再添加了一个版本，最后变成：version 1 -> version 2 -> version 3 -> version 2；
//单个文件恢复到旧版本
git checkout 哈希值 – 文件名
=================================================================
分支，Git中一个大杀器，可以这么理解，每个分支都是主线的一个备份，多个分支之间相互不影响，也就是在分支中做的开发，影响的仅仅是分支本身，不影响其他分支，也不影响marster，因此，开发的时候哪怕自己的功能只开发了一半，也可以保存到分支里面，因为你开发的不会影响到别人，只有到最终的全部开发完毕的时候，将分支合并入主线，这样你所开发的部分才会影响到每个人；
假如一个前端项目有5个人开发，一个功能往往不可能一下子就做完，很多时候需要好几天，然而我们为了保存进度，基本上每天都需要将自己做的那一部分保存，如果自己做的那部分只写了一半，然而做的这一半被别人checkout了，不说会不会影响到别人，光是这个一半是不是就是很尴尬，那么，如果有一条主线，这条主线代表了项目最终的形态，而每个人都有自己的一条支线，自己做的部分仅保存在支线里，这样就影响不到别人，一旦自己做的部分完成了，将做的合并进主线，这样合并进主线的部分才会被其他人checkout到；
主线，一半称为: master，也就是master这条线就是项目的各个阶段的最终版本；
创建分支
创建单独某个人的分支
//创建分支
git branch 分支名字
//比如，创建了一个叫做dev的分支
git branch dev
查看分支
//创建分支
git branch
切换分支
当使用git branch查看分支后，哪个分支前面有一个“*”号，那么哪个分支就是当前的分支，如果要切换
//切换分支
git checkout 分支名字
//比如切换到dev分支
git checkout dev
另外，新建分支，并且切换到新建分支，有一个快捷的合成写法
//创建一个分支并且切换到该分支下
git checkout -b 分支名字
//比如
git checkout -b dev2 //新建一个分支dev2并且切换到dev2下
删除分支
注意点是，不能在当前分支下，删除当前分支，如果要删除某个分支，必须处于其他分支下
//删除分支
git branch -d 分支名字
//比如
git branch -d dev2 //删除分支dev2
这种写法必须是dev2这个分支下没有commit的内容，如果有内容，要么先合并，要么强制删除
//强制删除
git branch -D 分支名字 //强制删除
一次性删除多个已合并的分支
//删除已合并的分支，除去当前所在的分支，除去master分支，除去develop分支
git branch --merged | grep -v ‘*|master|develop’ | xargs -n 1 git branch -d
如果还有别的分支要排除，那么就按找写法加进去，或者修改
合并分支
合并
如果要合并，首先得明确谁合并到谁，通常我们是将master作为主线的，因此也就是通常将别的支线合并到master
//切换到master下
git checkout master
//将某个分支合并到master
git merge dev //通过merge命令，将dev支线的内容合并到master下
上面说的是一种最理想的情况，一切都很顺利，但实际上，多人协同的时候，往往会出现合并的时候会发生冲突，为什么会发生冲突？原因也很简单，多人协同的时候，几个人同时创建了各自的分支，然后，其中的某个文件，a修改了，b也修改了，c也修改了，这时候a先合并进了master，等到b或者c去合并进主线的时候，文件已经不再是原来的那个文件了，如果b进行合并，那么a的内容就会被覆盖掉，因此这个时候合并就会失败，因为git不知道该这么处理了；
合并冲突解决
如果出现这种问题，该这么处理：
第一种：忽略此次合并，以master的为标准，其他分支的修改不作数，直接放弃
//忽略合并
最后：
总结来说，面试成功=基础知识+项目经验+表达技巧+运气。我们无法控制运气，但是我们可以在别的地方花更多时间，每个环节都提前做好准备。
面试一方面是为了找到工作，升职加薪，另一方面也是对于自我能力的考察。能够面试成功不仅仅是来自面试前的临时抱佛脚，更重要的是在平时学习和工作中不断积累和坚持，把每个知识点、每一次项目开发、每次遇到的难点知识，做好积累，实践和总结。
erged | grep -v ‘*|master|develop’ | xargs -n 1 git branch -d
如果还有别的分支要排除，那么就按找写法加进去，或者修改
合并分支
合并
如果要合并，首先得明确谁合并到谁，通常我们是将master作为主线的，因此也就是通常将别的支线合并到master
//切换到master下
git checkout master
//将某个分支合并到master
git merge dev //通过merge命令，将dev支线的内容合并到master下
上面说的是一种最理想的情况，一切都很顺利，但实际上，多人协同的时候，往往会出现合并的时候会发生冲突，为什么会发生冲突？原因也很简单，多人协同的时候，几个人同时创建了各自的分支，然后，其中的某个文件，a修改了，b也修改了，c也修改了，这时候a先合并进了master，等到b或者c去合并进主线的时候，文件已经不再是原来的那个文件了，如果b进行合并，那么a的内容就会被覆盖掉，因此这个时候合并就会失败，因为git不知道该这么处理了；
合并冲突解决
如果出现这种问题，该这么处理：
第一种：忽略此次合并，以master的为标准，其他分支的修改不作数，直接放弃
//忽略合并
最后：
总结来说，面试成功=基础知识+项目经验+表达技巧+运气。我们无法控制运气，但是我们可以在别的地方花更多时间，每个环节都提前做好准备。
面试一方面是为了找到工作，升职加薪，另一方面也是对于自我能力的考察。能够面试成功不仅仅是来自面试前的临时抱佛脚，更重要的是在平时学习和工作中不断积累和坚持，把每个知识点、每一次项目开发、每次遇到的难点知识，做好积累，实践和总结。
619
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
