环境部分略过
从0开始创建一个项目，用来讲解git，会包括创建远程新分支，回滚等操作。
在每一个讲解过程中都会有问题提问
- 基础部分讲解
- 实战高级部分
基础部分内容
如果在github上已有仓库 则通过idea进行clone
如果是在下面的界面则按照如下步骤
进行clone下载
如果是下面界面，则通过
和上面差不多
如果没有在github上已有项目、或者想要新建一个项目
通过IDEA 新建一个普通的工程（随便什么、maven也行）
如下图
TestGit的一个普通的maven项目（新建的一个工程是没有进行版本控制的）
第一步 引入VCS （version control System 首字母简称VCS）对应idea顶部的VCS选项 边上有 windows、Help
开启版本控制 如下图
这里选择Git 作为演示
如下图所示：截图中有解释
此时需要注意，这里的版本控制是 本地的仓库。
将提交分为 本地提交 和 远程提交 （需要登录github账号）
idea中登录github如下图
登录的方式有两种：
账号+密码登录 权限最高 拥有账号的所有权限
Token登录 权限由账号所有者创建，并且分配对应的权限
token的创建地址：https://github.com/settings/tokens
如下图：
如下图示例：需要选择分配的对应权限，以及填写Note（方便后面直接管理 主要是为了知道这个Token是那个一个Token）
创建后就可以将获取的Token直接用 IDEA 登录
本地提交
首先你需要注意 需要提交哪些文件 通过 选中文件 ===》 右键 ===》 git ==》add 将文件进行版本控制
新手常见的错误：
直接选中项目进行Add (会将一些不必要的文件也进行版本控制)
我给的建议是：
只需将 src 文件夹和 pom.xml文件进行Add操作，以及和代码相关的配置文件，对于以下文件
.idea文件夹
xxxxx.iml文件
这类文件由Idea自动生成的文件不进行提交，原因在于这些配置文件是你电脑上的环境设置。
如果将这些文件进行提交不利团队协同开发。
因为clone下来时会将这些文件也clone下来，这样对方的idea会使用项目下的配置文件，而不会加载 他自己电脑上的配置
具体有jdk版本和路径（对方很可能会找不到jdk，需要手动setup SDK）以及对方的idea使用习惯等设置都会是你自己电脑上的idea配置。因此不要直接选中项目进行Add
一定要自己手动选择对应的文件对于这类不必要的文件千万不要Add上去
撤销Add可以通过Ctrl Z撤销，也可以通过选中文件Git如下图
一般而言只需要Add src文件夹和 pom.xml文件即可
git提交时有这样一个特点，如果文件夹下面没有文件被进行版本控制，那么就当你提交上去时，会发现仓库中没有src等文件夹，只会有一个pom.xml文件。
也就是说Git只对文件进行版本控制，文件夹不会进行版本控制，这样也好理解。
进行一次本地提交
主要是为了后面演示产生一些数据，这里我在src中新建一个Hello类（包路径top.huashengshu）并且Add进去
提交按钮在工具栏上的√ 符号
当然也可以通过右键进行提交，也可以通过上面的VCS选项栏中的git进行提交。这里直接点击上面的按钮进行提交
本地提交直接点击Commit
远程提交则选择：
本地提交后查看日志
将项目 共享到github上的 远程仓库（没有则会创建、有则会提交，这里模拟直接创建）
需要登录github账户，然后会有如下弹框，输入仓库名称，描述，是否私有
对应github上的new
成功后如下图：
图标说明 ：
绿色的分支代表本地分支
黄色的是Head指针，本地提交会后这个黄色标签会跟着移动
上面的截图中错了，是3个分支记录，而Head黄色标记只是用来表示当前分支位置，提交的时候会根据黄色标记的分支进行后延操作
新建 本地分支
新建 远程分支
远程分支需要通过本地分支 push产生
也就是说push操作会触发创建分支、如果你还没有提交过远程分支，并且打算将本地分支推送到远程产生一个新的分支，如下操作
然后点击Push即可建立新分支。如下图去github上查看一下新建的分支
另外你还可以如下进行push 操作
另外你可以通过下面触发push
除此之外还以右键触发创建远程新分支
上面是比较基础的分支操作
高级部分
包括 冲突处理，分支回滚，错误提交处理
代码冲突处理
一般来说 一个大型的项目会有很多人共同开发，我们在日常使用Git操作的同时经常会提交和下拉代码
多人修改项目就会遇到一些问题
比如程序员A在晚上提交了一次代码
第二天 程序员A 和 程序员B上班了，第一件事情就是检查一下服务器上的代码有没有更新，也就是 下面的操作：
于是程序员B得到的代码是：
程序员A上班后 突然间想到了昨晚的代码中有bug存在，于是程序员A很快就改好了，并且将代码提交上去。
而程序员B之前git下来的版本是上面的版本。
程序员A提交代码后 远程仓库 的代码变成了
由于程序员B不知道程序员A又提交了代码，然后程序员B 在做完自己的代码后，程序员B 的电脑上代码是这样的
这个时候由于服务器上的版本已经被修改，为了确保程序员A的代码能保留下来，那么程序员push到主分支时需要进行代码整合如下：
这里由于代码行数不同直接进行了合并。因为程序员A和程序员B虽然操作通一个类，但是互不影响，直接进行合并了。
在上面commit and push中有提示这个类代码不同，并且 背景颜色为绿色是你自己的代码，而远程服务器是左边的窗口。
最终结果：
如果程序员B和程序A修改了同一行代码，则需要手动操作确认使用程序员A的代码还是程序员B的代码，还是都加入进去。
假设服务器版本是
都进行了更新项目，程序员A、B都修改了对方的代码，程序员A先提交如下：
B也修改了代码，并且两人都改动了同一行代码
让程序员A 先提交 ，A可以正常提交。B会提示
程序员B 操作：
如果选择Accept Yours则程序员A 的代码就会被覆盖
如果选择Accept Theirs则程序员B在改行的修改将不会生效提交上去。
如果选择merge 则进行手动选择（开发中一般都是选择这个，因为你需要知道程序员A改动后的代码）
合并后的结果会被拒绝push，因为需要先解决冲突，也就是说在本地先进行合并，合并后再将代码push到远程
这个时候不能通过按钮来操作，需要选择一个分支进行合并（将远程仓库和本地的一只分支进行合并）然后将该分支push上去
此时你会发现成功了，也很容易理解，合并后的代码只是多了程序员B自己修改好后的代码，对于git来说相当于只是一个人操作（重点），它认为是安全的自然就可以提交成功
最终的github上肯定也是程序员B合并好后本地的当前主分支，github上的最终结果如图
说明成功，并且解决了修改同一行代码的各种情况。
对于这种冲突问题，你需要在本地合并成一个分支，并且确保没有其他人再次提交代码，对于git来说一次只有一个人进行修改代码 ，如果多人修改代码，但是最终还是要保证在一个时间段内只能一个人修改代码，其他人也想提交代码，必须先解决冲突，然后提交。
如果程序员A 不断提交，然后程序员B必须等A提交结束后产生最终版本，程序员B将远程仓库的代码合并到本地仓库，解决了冲突问题后，进行提交。如果提交期间程序员A又提交了一次代码，那么程序B还要进行合并操作，合并后再提交（一个时间段内 只能有一个人提交成功）
代码回滚操作
以程序员A为例子：
程序员A本地的提交记录如下
首先需要了解回滚代码有四种形式 Soft、Mixed、Hard、Keep
要想分清Soft、mixed、hard、keep之间的区别，首先需要搞懂git是如何进行版本控制的，git的原理是什么。
git的原理：
git是通过判断文件的状态进行版本控制的，git又是怎么判断出文件的状态，git会将文件进行一个hash值算法，通过hash算法得到一个hash值，如果这个hash值和当前Head（我称为头指针）指向的当前分支的hash值比较，如果不同则说明当前文件已经被修改过（至少是和Head比较时是这样的）
那么修改过后的文件肯定会要求版本控制，在我们提交代码的时候他会判断当前的hash值与本地上一次更新项目的hash值比较。 首先会判断最近一次的从远处仓库获得的hash 和远程仓库中的head 执行的hash值比较。是否保持一致，是则说明不会产生冲突，因为代码只有你一个人修改。不是则说明远程仓库被人修改了，导致远程仓库head指针指向新的位置，hash值也就是新的hash值
这里有点像CAS算法 先判断服务的仓库文件是否有被修改。
我们对程序员B的提交记录分析：
会发现黄色的标签和绿色的以及紫色的都指向了同一个位置
其中黄色的标签是head指针指向的提交记录位置，而绿色的表示当前的提交记录（git进行上传操作的时候首先将本地进行提交一遍也就是绿色标记，提交过后黄色标记Head会指向绿色同一个位置）
当进行一次push进行一次远程提交时都是在某一个分支记录上进行push
此时 提交操作前 会判断服务器代码有没有被其他程序员修改过（通过比较hash值）
- 也就是说程序员B电脑上得保存上一次更新本地仓库时最近的一次更新时获得的hash值
- 将上一次的hash值与github此时的hash值进行比较。判断远程仓库文件是否被改动过。 如果改动过（同一个文件内的hash值）。此时hash值就不是原来的hash值、如果是这样就得将github的仓库和本地仓库合并，然后才能进行提交。如果没有改变说明没有人修改了github上的代码，那么可以直接提交上去，因为只有一个人改动代码）
在Git中有3个概念
- 提交记录
- 缓存区
- 工作区
工作区也就是我们idea实时修改代码和操作的时刻
缓存区是通过git Add命令以及Rollback命令手动选择需要进行版本控制的文件
提交记录是 将缓存区的文件提交上去
不会通过工作区提交，都是经过中间一层的缓存区进行提交
Soft、mixed、hard、keep之间的区别
idea中的提示是
上面关于Files won't change，指的是工作区（也就是你实时修改文件，不会改变文件中的内容）
soft和mixed都可以回滚，将head指针重新执行你选中的位置如下图，
但是两者的回滚区别在于soft 操作不会将缓存区的文件进行撤销而mixed会将缓存区的和分区记录相同
假设我们讲一个文件的加入缓存区，如下图通过右键add
红色的表示没有被git管理的文件，将其add进缓存区
之后文件的状态变成了绿色，表示文件被git管理了
如果我们只是进行soft的回滚，缓存区的状态不会改变，同时文件也不会改变
相当于soft只是讲head指针指向了你选择回滚的记录位置，当前文件状态如下，我们通过soft 回滚到第二次提交的位置
SOFT 和 MIXED
为了演示效果，我们进行提交一次，看下这台分支记录的先是怎么走的
只是本地提交，会发现多一只分支，其实mixed也可以达到这种效果，只要检测head执行的hash值和缓存区的不一样就可以进行提交
如果想改变文件的状态，比如取消某些文件的版本控制，我们可以选择mixed，他会回滚到选中的那个时刻。进行版本控制的文件，如果缓存区有一些文件没有在这个时刻被进行版本控制则会取消版本控制效果图如下。我这里只想将mixed到最初始的时刻
如果合并了则应该是和前面连在一起的
下面是刷新项目，可能会不显示所以刷新一下就行
HARD 和 KEEP
hard很容易理解，就是强制性的回滚，这种操作会所有状态都会回滚到选择的时刻，文件也会改变为之前提交的样子，代码也会回到之前，这个没什么演示的，一回滚就真的回滚过去了。而且再也回不到之前的状态。不像前面的soft和mixed
而Keep
我的理解是HARD和KEEP是对工作区进行操作
而Soft和Mixed是对缓存区操作
实战案例
程序员A 是老员工
程序B是新员工，由于误操作将.idea文件夹提交到远程仓库的github上了。导致程序员A需要以及其他员工需要把idea环境改成自己的环境，比如SDK
问题：
现在要求通过IDEA的Git操作将.idea文件夹从远程仓库github中删除，但是又不会将程序员B提交的代码给删除
解答：
我的处理方式是，在员工B的电脑上构建一个只含有正确整合后的代码，并且不把.idea文件夹包含进版本控制的一个缓存区
然后通过缓存区创建一个新的分支，去绕过错误提交.idea文件夹的那个分支。并将该分支设置为默认的分支
也就是通过mixed回滚到不包含.idea文件夹纳入版本控制，因为mixed方式不会吧工作区的代码修改，只是讲head指针指向了选择回滚的位置，当然是需要进行更新项目，先将远程合并到程序员B的本地仓库中，然后再mixed，接着需要手动Add操作将需要进行版本控制的文件添加到git的版本控制中。
最好通过push创建新分支
如下图操作
开始状态
在github上可以发现提交上去了，现在进行重整
这个时刻没有将其纳入版本控制，进行提交，如果出现下面的合并，一般选择your的版本，因为我这里是模拟，实际上代码肯定是本地工作区为准。
然后就可以进行push
成功后就会在github上找到创建的newBranch分支
下一步就设置他为默认分支（IDEA 中应该有对应的操作）
如果想要删除分支如下图
