Git操作
版本控制系统概述 ：
开发中的实际场景 ：
场景一：代码备份
小明负责的模块就要完成了，就在即将发布之前的一瞬间，电脑突然蓝屏，硬盘也突然光荣牺牲，几个月来的努力付之东流
场景二：代码还原（版本控制，也称代码状态存储，即以前的代码存储）
这个项目中需要一个很复杂的功能，老王摸索了一个星期，终于有了眉目，可是这被改得面目全非的代码，已经基本回不到从前了
场景三：协同开发
小刚和小强先后从文件服务器上下载了同一个文件：UserDao.java
小刚在UserDao.java文件中的第30行声明了一个方法，叫count()，先保存到了文件服务器上
小强在UserDao.java文件中的第30行声明了一个方法，叫sum()，也随后保存到了文件服务器上
于是，count()方法就只存在于小刚的记忆中了
因为会覆盖同一行，是文件服务器的基本操作，可能有些文件服务器会解决这个问题
但基本解决不了，或者解决会非常的困难，也有可能会降低大量的性能，得不偿失
场景四：追溯问题代码（编写人和编写时间）
老王是另一位项目经理，每次因为项目进度挨骂之后，他都不知道该扣哪个程序员的工资，就拿这次来说吧
有个Bug调试了30多个小时才知道是因为相关属性没有在应用初始化时赋值，可是赵四、能能、老七 都不承认是自己干的
版本控制系统 ：
版本控制系统能追踪项目，从开始到结束的整个过程，对编程人员而言，版本控制技术是团队协作开发的桥梁
助力于多人协作同步进行大型项目开发
软件版本控制系统的核心任务：查阅项目历史操作记录、实现协同开发
常见的两种版本控制类型：
集中式版本控制工具（一直操作同一个仓库）：
集中式版本控制工具，版本仓库是集中存放在中央服务器的，team里每个人工作时，从中央服务器下载代码
每个人个人修改后，提交到中央版本仓库，提交（commit）代码需要联网（到中央服务器）
如：SVN
集中式：都在一个节点里进行操作
分布式版本控制工具（分开操作仓库，最后操作同一个仓库）：
分布式版本控制系统可以没有 “中央服务器”，每个人的电脑上都是一个完整的版本仓库，这样工作的时候，不需要联网
因为版本仓库就在你自己的电脑上，多人协作只需要各自修改，开发完成即可
推送给对方，也就是远程仓库（联网，即下面先到远程仓库再到对方），推送的时候是将整个版本仓库推过去
如：Git
Git 简介：
Git — The stupid content tracker，傻瓜内容跟踪器，Linus Torvalds 是这样介绍 Git 的
Git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目的版本管理
Git之父 是 Linus Torvalds，Git是为了帮助管理 Linux 内核开发而开发的一个的版本控制软件，最后开源了
速度、简单的设计
对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
完全分布式（每个人的电脑都相当于是一个版本库）
分布式：将总节点分成若干个子节点，子节点的操作后，最后交给总节点操作，即最后再统一操作
如Git就可以将本地仓库看成远程仓库的一个节点，也就是将操作放到这些节点里，最后再放入远程仓库，所以是完全分布式的
有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）
Git工作流程图：
上面就是Git本地仓库与远程仓库直接的交互流程图
图解：
冲突问题基本解决不了，所以基本是谁后下班谁解决
而之所以先拉取再提交，是防止推送时，出现代码冲突，而这个冲突我们可以用拉取来判断解决
其中拉取的冲突和推送的冲突，是不一样的
拉取是进行覆盖，即空的可以覆盖空的，不为空的覆盖空的，相同代码进行覆盖
而其他不同部分，则发生冲突（在一个文件下），如空的覆盖不为空的，对应同一个代码不同等等
一般会根据修改时间，进行文件的确定，拉取或者推送时，都会得到修改时间，而这些修改时间一般会进行合并
拉取，则是对方覆盖我方，若是推送，则是根据最新状态来操作是否冲突，这两个后面对拉取和推送的说明会更加的详细说明
而之所以先使用拉取，是因为一般的推送基本都会出现冲突，因为其他人进行推送时，会多出一些代码（状态不同冲突，自己推送自然可以一直操作，即覆盖，因为是自己推送的，所以推送通常只是考虑状态，而非真实的覆盖冲突，这是拉取才会有的）
所以现在我们改变对应远程仓库时，若进行推送就会出现提示，推送不了，即需要先进行拉取，才会让你推送
而这些代码我们基本没有，那么由于不能改变远程仓库本来的代码，那么基本会出现冲突
所以说推送时出现的冲突的出现是远远大于拉取的，因为其他人也是在修改
且防止手抖了使用了强制推送，使得被覆盖了，这是非常危险的操作
在后面拉取知识中时，会说明为什么要先进行拉取，而不是推送
操作：
Clone：克隆，从远程仓库中克隆代码到本地仓库，第一次操作（基本会顺便进行检出）
Push：推送，代码完成后，需要和团队成员共享代码时，将代码推送到远程仓库（也会出现代码冲突，但一般都会使用拉取解决）
Pull：拉取，从远程库拉代码到本地库，自动进行合并(merge)，最后放到工作区
克隆基本没有代码冲突，但是却耗时最长（特别是大项目），且经常需要进行更新时，不可能每次更新都克隆一下，太麻烦了
拉取虽然有代码冲突，但是可以随时更新，且速度快
拉取冲突出现：拉取进行合并时，一般都会判断文件的修改时间是否一致
不一致就会检查文件里是否有不一致且在同一位置的代码（基本是同一行）
然后出现冲突提示，使得停止拉取（只是这个文件没有进行数据添加），其他文件没有冲突的会进行拉取
所以一般在第一次操作时，需要克隆，其他都进行拉取
上面就是Git本地仓库操作流程
操作：
checkout：将克隆的仓库的分支检出到工作区
add：在提交前先将代码提交到暂存区
commit：提交到本地仓库
基本概念：
本地仓库： 在本地主机上的一个代码库，可以独立存在，也可以与远程仓库进行关联
工作区：对任何文件的修订(增删改)，都先放在工作区，工作区不与任何仓库分支进行关联
暂存区：把修订的文件，从工作区经过add（添加）后与某一个仓库分支进行关联
只要进入缓存区（暂存区也可以称作缓存区）的文件才能commit（提交）到本地仓库
远程仓库 ： 在局域网或互联网上的一个主机，存放代码库的主机或平台，比如GitHub、Gitee.com(码云)
分支：代码存放在仓库，默认是主分支(master)，可以在主分支基础上创建很多子分支，实际上并没有规定只能在主分支上创建
子分支也可以创建分支，只是默认master而已，即也可以将其他分支作为主分支
比如develop（开发）、bugfix（bug修复）等，子分支的代码是主分支复制过来的，即子分支操作的代码，不会影响主分支
如子分支产生了bug或者报错了，主分支的代码还是原来的样子（因为不影响）
且当操作完毕后（那么基本是开发完毕），可以将子分支与主分支合并，相当于我们将主分支的操作交给子分支了
所以设置子分支的好处就是：对于自己来说，防止在主分支操作代码时，出现问题，或者思路错了
代码突然回不去了（一般都可以回去，只是防止而已），主要是出错不好维护，分工明确的好维护
对于远程总的大型项目来说，对应基本也有分支
且可以是对应部分代码，且会被我们得到
而不是整体得到，防止被改变，影响远程总项目，就算获得全部项目（一般不会获得），但获得速度慢
一个文件夹包含.git隐藏目录（Git工作目录），说明此文件目录使用Git版本管理
.git隐藏目录中存储了很多配置信息、日志信息和文件版本信息、暂存区信息等
.git文件夹中有很多文件，其中有一个index文件就是暂存区，也可以叫做stage，暂存区是一个临时保存修改文件的地方
图解：
只有当特定情况下才会进行出现相应的文件，如使用add命令将文件添加到暂存区后，对应的index文件才会出现
而一般的命令指定路径，基本都是工作区，从图中知道，工作区就是.git所在目录下的区域（不是.git目录下，即不是.git目录里面）
小结 ：
Git分布式的版本控制系统
Git解决那些问题：代码备份、还原，协同开发，多版本同时开发、追溯问题代码
Git中的基本概念：
本地仓库：存储所有版本代码
工作区：编辑代码区
暂存区：准备提交的代码都放这里
远程仓库：用于团队之间共享代码（枢纽）
分支：多个版本同时开发，master主分支，develop开发分支，test测试分支等等
基本上想创建多少个就创建多少个，只要不超过硬盘空间，而之所以一般创建上面的这些名称
是因为上面的这样创建的这些名称可以见名知意
Git工作流程：
远程仓库操作：
clone（克隆）：第一次从远程仓库下载代码（一般我们都要进行克隆，而不是推送，第一个程序员才是推送）
pull（拉取）：获取团队其他成员代码提交变动
push（推送）：完成后的代码上传到远程仓库
本地仓库操作：
checkout（检出）：将本地仓库的内容检出到工作区（一般与克隆一起）
add（添加）：向暂存区添加代码，准备提交
commit（提交）：把暂存区的代码提交到本地仓库
Git的下载与安装：
下载与安装：
下载地址： https://git-scm.com/download
软件安装：
下载完成后可以得到如下安装文件：
双击安装：
一路"下一步"使用默认选项即可
双击下载的安装文件来安装Git，安装完成后在电脑桌面（也可以是其他目录）点击右键
如果能够看到如下两个菜单则说明Git安装成功
备注：
Git GUI：Git提供的图形界面工具
Git Bash：Git提供的命令行工具（一般都用这个，看个人习惯，这里用的就是这个）
Git基本配置：
基本配置：
安装完成 Git 后，正式使用git前，是需要进行一些全局设置的，如用户名、邮箱
设置的主要命令是 git config ：
我们点击Git Bash Here进入命令界面，输入以下命令：
其中， --global 指定为全局配置，若使用这个参数命令，可以在任意目录下进行操作
不使用该参数，则为当前所在仓库配置
即需要必须在对应工作区或者.git目录（本地仓库里面所有地方，包括目录的目录）里进行操作
其他目录会报错，即找不到对应git目录（not in a git directory）
而我们也可以不进行设置，但这样的设置会知道是谁操作的对应代码，即谁进行推送等等
通过上面的命令设置的信息会保存在.gitconfig文件中（一般都存放在用户目录里面的用户名目录里面，如下图）
以上配置信息默认存储在用户目录下，每次设置时，若这个.gitconfig文件没有则创建后设置
有的话，若有对应设置则覆盖对应设置，否则就添加对应设置
当然，若出现不知道的错误，也可以直接删除以下如图文件，重新操作以上命令即可
查看配置信息：
git config --list
当然，上面显示的红色框里面的是全局的设置，若你在本地仓库使用git config --list 时，那么上面红色框后面还有对应的信息
代表这本地的信息，而本地也可设置红色框里面的信息
所以，在本地使用这个git config --list 时，可能会出现两个红色框中一模一样的信息（故意在本地设置成这样）
但在不故意的情况下，通常不会一样
注意：这里不完全是Linux的操作（但基本也算是）
如对应的参数（就是"–参数"，当然也能叫做命令）或者命令的位置基本不能随便放
主命令除外，主命令在Git里是 “git 主命令”，这个git也可以是大小写忽略，其他的命令不能改变大小写，包括参数
除非本来就有对应的作用
主命令在Git和Linux中就是对应二进制的执行文件，一般都要写在最前面，位置是基本不能改变的
且可能对应的命令或者参数写了，但被忽略，但是其他的操作有些与Linux基本类似，因为Git与Linux都是同一个人写的
即Git的命令与Linux的命令有些是相似的且作用基本一样（如touch对已经存在的文件或者目录进行操作时，是修改创建时间）
如Git也可以操作cd，mkdir，touch等等命令，但也只是有些，不是所有，如yum
但Linux也不能操作"–list"命令，即他们只是有共同的命令而已，但这个共同命令基本都是基础命令，如目录的操作等等
当然不只是命令，一些快捷键也是有共同的，如tab补全信息
即当在一个目录下，打出一段名称，而这一段名称在该目录下
若只有一个文件名称（大小写忽略，而Linux不可以）是有对应的，那么按下tab键，就会补全全部名称
若有多个文件名称是有对应的，如louyt.txt，和loupi.txt，那么打出lo，只会补全他们共同的有对应的，即lou
所以这时我们需要更加的具体，使得只有一个文件名称是有对应的，如louy，那么就会补全louyt.txt了
若只有一个文件，那么可以直接按下tab
但要注意空格，因为不可能连接起来
tab也会帮你自动打空格，没有当前单词的补全的情况下以及没有写上该文件后面的参数的情况下
就会补全该文件的全部名称，只有在特定命令时才会出现，如add，commit等命令，而vi，cd等不会
全部名称肯定是包括后缀名的，要不然怎么不是叫做名称，而是全部名称呢
所以也可以说，常见的Linux命令或者基础的Linux命令以及一些基本操作他（Git）基本都可以操作
那么为什么Git对应的操作文件或者目录是可以大小写忽略呢，主要是他操作的是Windows的文件系统，不是Linux的文件系统
而windows的文件系统对应的文件的大小写就是一样的，所以Git操作的文件和目录是可以大小写的
而Liunx的对应的文件或者目录的大小写不是一样的
所以操作的文件和目录大小写就是两个不同文件，即tab的补全也就需要对应具体的名称了（不能大小写了）
对于上面说的命令忽略是很少情况下才会出现，但还是有，看如下解释：
对于git config --global user.email “your email” 命令来说，一般所有目录都可以操作
但git config user.email “your email” --global在不是对应git目录（工作区及其本地仓库目录里面，包括目录的目录）下时
会报错，但报错的不是命令错误，而是对应的找不到对应git目录（not in a git directory）
一般的像在后面加上什么"–yyyy"（随便写的参数命令）的基本会出现命令错误
但我们发现，当在对应git目录时（工作区及其本地仓库目录里面，包括目录的目录）
使用git config user.email "your email"命令，后面无论加上什么，都被忽略了
所以可以知道，在git里面，有些操作中，自带停止识别命令，使得后面的命令不操作（也就是忽略），也就不会执行
最后注意：若窗口过小，会出现对应的：模式，这时可以使用q退出
若不使用q，可以放大窗口会将原来窗口显示出来的放在最上面
后面的依次根据窗口显示，若查询结果全部出现，那么会自动退出
否则需要"上按键"来使得前面按过"下按键"的显示出来，直到全部显示，则自动退出
若出现了END的话，代表到底部时，再次按下"下按键"，就会出现，即不能再按"下按键"了，即代表结果的末尾
构建本地仓库 ：
要使用Git对我们的代码进行版本控制，首先需要构建本地仓库
通常有两种方式：
在本地初始化一个Git仓库
从远程仓库克隆一个仓库 （远程仓库演示）
初始化本地Git仓库：
在电脑的任意位置创建一个空目录（例如local_repo1）作为我们的本地Git仓库
进入这个目录中，点击右键打开Git bash窗口（哪个目录下打开，就是操作哪个目录）
执行命令Git init如果在当前目录中看到.git文件夹（此文件夹为隐藏文件夹，需要显示隐藏文件夹）则说明Git仓库创建成
上面的隐藏的项目勾选上（这是我的电脑操作，你的电脑操作与我的电脑操作可能会不同，一般位置或者显示不同）
本地仓库的操作（重点）
创建 Git 版本库：
在本地创建 Git 版本库，需要使用 git init 命令
首先，你需要新建一个存放版本库的目录，然后进入到该目录所在路径，打开Git bash窗口，然后执行：
git init
然后查看目录结构中，就可以看到包含有 .git 子目录，这就说明创建版本库成功了
查看当前文件状态（即可以被添加的文件或者目录）：
显示了No commits yet则是还没有提交过，即没有对应L配置文件信息还什么都没有
On branch master代表当前分支是master来操作的（默认的主分支）
??代表着没有被添加，但可以被（被我添加）添加（空目录就不会显示出来，因为不能被添加）
将文件添加（修改）到版本库：
要将一个文件纳入到版本库管理，首先要将其添加到暂存区，然后才能提交到仓库中
将文件添加到暂存区，使用的是 git add ：
git add Readme.txt
git add .
注意：这边空文件夹是不会被添加到暂存区中的（甚至不会显示在状态里面，即不可以被添加）
A代表已经被添加了，即已经存在了暂存区
注意：暂存区会存放原文件的多种状态，也就是说，暂存区的文件有多种状态（也可以叫做文件夹）
一般有如下几种状态，如图（使用git status命令，不加-s）：
加是-s就是：
其中Changes to be committed：英文意思：代表要提交的更改
可以理解为就是可以提交的文件，假设为一个P配置文件的A分隔符
Changes not staged for commit：英文意思：未提交而暂存的更改
可以理解为被修改的文件，假设为一个P配置文件的B分隔符
两个分隔符的内容就是他们的下面，他们互不干扰（检查操作），后面会多次说到这两个分隔符
Untracked files：英文意思：没有追踪的文件，可以理解为没有进行添加的文件，就在工作区里
A代表new file，也就是新添加的文件，M代表modified，也就是修改了这个文件，??代表没有进行添加操作
只有A分隔符对应的显示是绿色，其他的一般都是红色
实际上还有一个D，如图：
D就代表deleted，也就是删除了这个文件
上面就是暂存区存放的文件的状态，当我们操作原文件时
如新添加的文件时，也是先创建对应添加的文件，再操作p配置文件
没有A分隔符，就创建A分隔符（创建A分隔符时，其他分隔符就会删除），并在对应的A分隔符下面添加或替换上这个文件映射
在添加或者提交的基础上进行修改或者删除操作时
若是修改，则先创建对应修改的文件，再操作P配置文件
没有B分隔符，就创建B分隔符，并在对应的B分隔符下面添加或替换上这个修改的文件映射
这里要注意，判断对应文件的修改不会根据修改时间，还是文件内容，即这里与冲突的那个判断不同
若是删除，则不会创建对应文件，没有B分隔符，就创建B分隔符，也不会添加上对应的文件映射
但会在B分隔符下面加上对应配置，使得显示时，显示出对应的删除显示
若操作修改和删除时，再次添加时，如果是修改那么合并，若是删除，则删除对应原文件
而使用git status命令或者git status -s命令时
就会根据P配置文件的A分隔符下面内容或者B分隔符下面内容的映射来决定是否有内容进行显示
一般我们在提交暂存区的文件时，一般提交的是B分隔符的对应映射文件，然后对应A分隔符的文件也删除
若B分隔符的所有对应映射都没有（一般对应映射的文件没了，那么映射也就会没有），或者对应删除配置没有了
则提交A分隔符的对应映射文件
当然若文件都删除了，那么B分隔符所有对应映射也就没有了，但他这个映射配置并没有删除，即B分隔符并没有删除
所以提交时，也就是根据删除配置来提交，即空的
提交过其他的文件时，就会提示（nothing to commit, working tree clean），后面英文意思是：把树清理干净
其他的提示我们不多说了，提示有非常多的，不可能依次说明
但只要记住，提交空的，提交不了就对了（在第一次提交的情况下），因为必须要有文件存放信息
所以上面的modified和deleted一般是看B分隔符是否存在，而出现对应的显示
即Changes not staged for commit和他下面的modified或者deleted
当提交后，就会出现对应数据放在某个L配置文件里（这里就有对应文件信息了，解释有对应文件信息的操作）
实际上显示或者添加时，会读取这个L配置文件，刚刚开始是什么都没有的
若你提交一个A文件，提交后，P配置文件的A分隔符和B分隔符就会删除这个A文件和对应的映射
且L配置文件就会出现关于这个A文件的信息，那么下次添加时或者直接看显示时
会读取L配置文件看看这个文件是否已经提交过并且没有B分隔符，若提交过并且没有B分隔符，则不会进行添加或者显示
但却可以直接进行修改和删除（L配置的作用，优先于P配置文件读取），这时就只有B分隔符了，在有B分隔符时，无论是否提交
都是可以进行添加的（就算没有对应文件），将B分隔符的文件复制到A分隔符下面
但由于L的配置文件有这个A文件的信息
所以再次添加的就不是新的文件了，也就不是new file了
若是修改则是是绿色的modified（添加修改的文件）
若是删除则是绿色的deleted
在复制时，复制删除出现的配置，因为复制也是要去B分隔符的找文件映射的（删除就找到了对应配置）
这时就会删除B分隔符，除非再次进行修改或者删除
这时就又可以操作这个修改或者删除的文件了，当然也可以不操作而直接提交
那么实际上就与不添加而直接提交一样的
这是P配置文件的操作，当创建A分隔符时，其他分隔符就会删除
但若不进行添加，而直接提交，前面说过，提交时，是提交B分隔符的
所以也会进行提交，那么就会提交对应映射文件（修改操作）
若没有，就提交删除配置（删除操作），这时可以提交，因为不是第一次提交了，有对应文件存放，即不是空的
但提交了对应删除配置，提交会做特殊处理放入对应文件里，即回退时，根据这个文件操作时，相当于没有对应文件回退
若提交的是最后一个文件，那么对应的A分隔符和B分隔符就会删除
所以显示的Changes to be committed和Changes not staged for commit也就没有了
提交也是可以提交多个文件的，如git commit kk ll -m “a”
那么就算依次提交，即先提交kk文件，再提交ll文件，若只有这两个文件在暂存区，那么ll文件也就是最后一个文件了
所以最后不会显示Changes not staged for commit，注意：虽然是依次提交，但对应的信息是存放在一个回退文件里的
回退文件：提交后产生的文件，可以进行回退，即通过这个文件，可以得到对应文件信息，git实际上是通过回退文件的连接来操作
当提交命令结束，才会进行创建回退文件，即在一个回退文件里（回退文件，可以进行还原的文件，存放对应文件信息）
上面的P配置文件和L配置文件实际上只是我创建的一个别名，对应的A分隔符和B分隔符也是一样的
而Git的操作也类似于上面的解释
而正是因为暂存区可以通过状态管理，使得操作原文件（第一次，也就是没有提交时，必须先添加，基本也就是不能操作的文件）
即添加的文件的修改或者删除基本可以回退或者再次修改
只有提交时，才算是真正的修改成功
所以我们也一般将暂存区称之为版本控制，实现可以还原
将暂存区中的文件，提交到仓库中（本地仓库），需要使用 git commit ：
git commit
git commit -m 'your comments'
注意：这边直接用 git commit 提交，会先弹出添加评论的页面（具体操作方式可以百度），所以一般的我们使用git commit -m “对应的说明内容”
提交后暂存区的对应文件或者目录就没有了
对于要进行修改本地仓库的对应文件，由于我们基本不可以提交一个一模一样的，所以也就基本修改不了，看如下操作：
先说明一下上面的显示： 1 file changed, 0 insertions(+), 0 deletions(-)，他的意思是：1个文件已更改，0插入，0删除
这是添加一个新的文件，也就是本地仓库新得到的对应文件的显示提示
好，到这里就要说明一下，若你再次添加时，由于修改日期没有变化（或者文件没有变化）
那么是添加不了的，但不会报错，只是没有添加，这就是对于不能修改的原因
而当你修改对应的提交后的文件时，也就是改变修改日期（或者其他有变化）
若你是添加一些数据到该文件里面，如添加4行数据，那么提交时上面就是4插入，没有显示删除这个提示
若你再次修改，修改了第2行和第3行数据
那么会检查是否有不一样的，如果有某行数据不一样，那么删除这一行，再进行插入，所以修改了两行后，上面就是2插入，2删除
若是删除后提交，对应删除所对应配置文件会记录删除的条数，使得提交时显示出来
最后注意：每次提交都会有一个文件状态，也就是提交后的当时的文件状态
这个状态与暂存区的不同，他是可以使得回退到提交后的工作区文件的情况的
这里的解释和回退的操作在后面会说明
这是在同一个分支的内部进行提交，所以并没有冲突
因为在同一个分支里，操作的话，对应数据那就是当作没有作用的，即可以删除
而不同分支就会有冲突，当然不同的本地仓库与远程仓库之间也会有，后面会说明远程仓库冲突
是因为对应的数据是有作用的，也就是不能删除（如远程仓库的一些代码是其他同事写的）
虽然分支都是自己写的，但也要防止自己不小心改变了其他分支代码，所有也要有冲突
而之所以冲突只在仓库之间操作，是因为他是真正存放对应信息的地方
在这里我就要说明一些，中文设置或者乱码解决方式
中文设置：
点击Git bash窗口中这个地方
然后再点击Options…这个选项，然后选择Window，再UI language中选择zh_CN
那么就可以设置中文的选项界面了
不是全部变成中文界面，只是选项窗口界面变成中文，命令窗口并没有变成中文，如上图中的其他英文
之后就是这样的效果：
这里我首先说明一下编码和解码的区别，对于编码就是数据到二进制，解码就是二进制到数据
而我们说使用什么编码，如使用UTF-8编码就是使用他进行解码或者编码的操作（即也可以叫做UTF-8解码）
只是我们通常叫做某某编码而已（因为主要参照二进制），也可以说明是UTF-8编码方式和UTF-8解码方式的总称
而对应的编码和解码都对应一个字符集
实际上对应设置编码（通常这样说明）时，都会有一个字符集，如UTF-8有一个对应的字符集Unicode
字符集可以看成是编码和解码的参照对象，我们看到的，都是对应解码出现的对应图案，而编码就是将这些图案变成对应的二进制
所以说数据也可以称之为对应图案
对应解码时，根据二进制对应的图案显示给我们看，他就是存放了这些图案，所以乱码出现的图案也是他上面的，只是不正常而已
那么接下来就说明一下乱码问题：
出现乱码的主要形式是：
1：编码方式和解码方式不同
2：对应编码方式或者解码方式不识别对应数据（即需要支持对于数据，如ASCLL识别中文会出现乱码）
那么接下来分析一下上面提交时可能会出现的乱码问题
首先我们知道我们需要操作的是中文
那么我们应该使得编码方式和解码方式都一般设置为UTF-8（当然可以识别的也可以设置，一般都是UTF-8）
首先我们点击上图中的文本，如图：
这里设置的是将我们发送的数据进行的编码，如我们提交时，使用git commit aaa -m “啊”
这个"啊"字变成对应的二进制，也就是编码成二进制，那么谁来操作解码呢，由于我们操作的是文件系统
那么解码方式一般是当前所在系统的解码方式，而我这里的系统是Windows，那么应该这个解码方式是Windows系统来操作的
一般的，我们的Windows的解码是可以操作UTF-8的，但是可能会操作不了（即解码方式不同）
那么我们就需要改变对应的解码方式
我们点击win，搜索区域（系统的设置），即系统设置里的区域设置，找到管理语言设置，如图：
我的电脑是这样的，可能你的电脑不是这样的显示，即需要你自己找到对应位置了
我们可以看到右边的语言设置，点击更改系统区域设置，然后进入下图：
根据他的介绍，只有在不支持Unicode（实际上也就是UTF-8的字符集，一般设置UTF-8那么对应的字符集就是这个）时
才使用对应的解码方式，上面就是中文（识别中文的解码），而支持时，并没有说明（一般使用系统默认的）
而这个就是出现乱码的原因之一（基本是这样），所以有些电脑可能在Git提交时就会出现乱码
但上面也有一个选项，Beta版，根据介绍
我们发现，是设置UTF-8的，实际上就是设置系统的编码方式，我们点击这个，然后确定
那么对应Git提交出现的乱码问题就可以解决了，如提交时，对应出现的乱码问题
当然若你不想点击，可以找到对应的配置文件进行操作，至于如何操作，去看百度吧
但要注意：基本只有与系统相关的才会进行对应默认解码方式，因为不与系统相关的话，对应的编码或者解码是不操作的
因为根本就没有使用这个解码，所以你会发现，当你设置这个时，有些地方的显示发生了改变，有些没有发生改变
最后要说明一下，当你改变时，可能有些程序会运行不了，因为原本他可能与系统编码是一样的
当你改变后就不一样的，即出现了对应乱码使得报错，如改变后，idea若放在有中文路径的地方，可能会出现错误
所以若只使用Git时，那么可以设置，否则最好不要设置Beta版，使得可能出现程序执行不了（虽然放在英文路径可以）
所以英文路径是比中文路径要好的
查看提交历史记录：
有的时候，是会需要查看自己做过哪些提交，来回顾自己完成的部分，或者需要寻找某个具体的提交来
查看当时的代码，这里需要用到：
git log
git log --pretty=oneline
在 git log 的输出内容中，可以看到每次提交的 ID（下面就是commit），是一个 40 位的字符串
为什么要这样呢，是为了可以进行回退而形成的名称，基本是得到的名称是不可能一样的（几率非常非常小）
即我们可以通过这个名称来得到不同的提交文件
在前面说过（前面的说明），提交的状态与暂存区的状态不同，他存放了当时工作区所对应的文件信息
也就是说，提交后，将当时的对应提交的暂存区的文件（与工作区是对应的）和对应提交后的日志信息存放好
回退时，返回工作区，和对应日志信息（提交的历史记录，即后面的git log命令和git log --pretty=oneline命令）
这时我们再次查看日志信息时，发现，在当时提交的文件后提交的日志（记录）没有了，注意：只是记录没有了
但对应的文件还在，可以任然可以通过名称得到当时的状态信息，只是需要我们手动的去objects文件夹里找了
但很难找到（因为不知道是那个文件），后面会说明这个问题
其中我们在回退时
暂存区对应的分隔符包括分隔符内容和暂存区对应的工作区文件会全部清除（没有在暂存区的对应工作区的文件不会）
然后将当时提交的文件存放在（回退到）工作区中，所以我们发现暂存区就是一个中转站
实际上暂存区也可以进行回退操作（只是回退操作，而不是回退文件，如回退修改等等）
即他使得原文件，与修改原文件产生关系，让我们进行一系列的操作，最后提交我们想要的文件
而正是因为提交的都是暂存区的（工作区，没有暂存区的那些作用，所以使用暂存区）
所以他也就控制了对应还原，即我们也叫暂存区称为版本控制
接下来举个例子：若在当时有一个a文件的添加，那么提交后，我们发现，工作区有一个a的文件（被打了标记）
说明他在暂存区的对应文件已经被提交了，如图所示：
这个勾表示被提交，提交后，会生成对应文件放在objects里面，他就存放了回退文件信息
当我们删除他时，可以使用回退来再次得到，可以使用下面的操作来进行
如我提交了三次，若我需要得到第一次的提交的状态，就可以通过当时提交时形成的名称，来进行回退
下面操作git log命令：
Author表示作者：若设置了.git的对应名称和邮箱，则使用.git的，否则使用全局的，如当.git有名称无邮箱，但全局有名称有邮箱时
那么使用git的名称，全局的邮箱，所以名称和邮箱并不是只是使用.git和全局一起的，而是各自进行判断全局和.git的操作
即优先使用.git，但要注意，必须要有名称和邮箱其中一个
否则都没有的话，提交不了，而只有一个时，另外一个显示 unknown（英文意思：未知的）
下面操作git log --pretty=oneline命令：
后提交的显示在前面（如上面的第二次提交）
实际上他们存放在.git的objects文件夹里，这里就是提交到本地仓库的回退文件夹，如图
我们发现这里有两个数的文件夹，我们观察上面的commit的值有：
6e2648347d180196938164eb6a03894d27104c06和f52867c15d6749ec8b0b9cb8c8b89a917c8aaf2e
发现他们的最前面两个是6e和f5，这时可以发现，图中有6e和f5的文件夹，我们点进去看看，如图：
6e文件夹：
f5文件夹：
发现objects的确是存放本地仓库可以进行回退文件的文件夹
将对应的文件内容信息，不是回退文件全部信息，统称为本地仓库文件
他里面包含了文件信息，所有可以通过这个文件来返回提交的文件
版本回退：
有了 git log 来查看提交的历史记录，我们就可以通过 git reset --hard 来回退到我们需要的特定版本
然后使用当时的代码进行各种操作
git reset --hard 'commit_id'
我们在进行回退时，指定的就是objects里面所对应的文件名称，我们会执行该文件的内容，使得回退，该内容则是存放当时的状态
得到当时对应的文件，放在工作区
顺便将暂存区对应的分隔符包括分隔符内容和暂存区对应的工作区文件会全部清除（没有在暂存区的对应工作区的文件不会）
回到未来的某个提交：
前面我们说过，对应后提交的记录不会显示出来，而我们在objects文件夹里找非常困难（因为不知道是那个文件）
接下来我们解决这个问题：
当退回到某个提交的版本以后
再通过 git log（返回提交记录和对应名称） 是无法显示在这之后的提交信息的（因为是根据时间来判断的）
但是，通过 git reflog（返回提交的详细记录和对应回退的简化名称，包括之后的提交信息，相当于简化的强化的git log命令）
没有显示时间，即不是根据时间来判断的
可以获取到提交操作命令的历史
注意：上面的记录也可以说是当前分支的提交的状态
因此，想要回到未来的某个提交，先通过 git reflog 从历史命令中找到想要回到的提交版本的 ID，然后通过 git reset --hard 来切换
git reflog
git reset --hard 'commit_id'
发现也多出了回退的信息
这时我们也可以发现git reset --hard 'commit_id’命令
实际上也可以操作前7位数的名称对应的全名称，（实际上相同的几率也是很小的）
也相当于对应状态的别名，可以通过这个别名，也找到当时状态的回退文件
上面的（HEAD -> master）表示我们所在的状态（没有提交的就不会出现，如刚刚初始化的时候）
提交后，保存当时文件状态，即L配置文件（显示是看这个L配置文件的），即对应的HEAD -> master显示在当前状态
这时就要提一点，若我们git reset --hard像这样的直接写，那么就是回退到当前的状态，实际上当我们使用git init时
会默认一个状态（刚开始就是没有文件回退，且这是开始状态，其他的是其他状态）
即返回，放在Q配置文件里的默认位置，我们使用git reset --hard命令
就是去这个Q配置文件进行状态的返回，也就是说，每次提交Q配置都会有对应的映射指定回退文件，回退后
再将这个回退文件映射添加到默认的映射位置，当不指定ID时，就使用默认的映射回退文件
上面的Q配置文件与P配置文件和L配置文件都是假设的，实际上Git也是类似的操作
删除文件：
一般的，我们可以删除工作区文件，使得暂存区有删除配置，是可以进行还原（删除配置有对应删除文件信息）的，可以使用：
git checkout 具体的文件全名
在文件未添加到暂存区之前，对想删除文件可以直接物理删除不能还原
如果文件已经被提交，且不能还原，一般需要 git rm 来删除：
git rm Readme.md
实际上就是删除工作区文件后，再次进行添加操作，这两个操作的总和，使得只有A分隔符
我们也可以手动的操作，如先删除，再添加
注意： git rm 只能删除已经提交到版本库中的文件，其他状态的文件直接用这个命令操作是出错的
上面只是显示给我们看的，虽然实际上确实是删除了，但状态没有被删除，只是我们不能还原原来的文件了，因为他也基本在对应的A分隔符，还原不了了
添加文件至忽略列表：
一般在工作区中，并不是所有文件都需要纳入版本控制的
这种不需要进行版本控制的通常都是些自动生成的文件比如：
idea工程文件(springmvc.iml)、编译后文件target、系统上传的图片img（虽然自动生成的会覆盖，但没必要）
在这种情况下，我们可以在工作目录中创建一个名为 .gitignore 的文件（文件名称固定），列出要忽略的文件
我们可以使用vim来创建保存 .gitignore 的文件，如图：
在普通模式下，可以按住shift+zz（小写zz）保存退出
注意：每次我们在进行添加时，都会找工作区是否有.gitignore文件（即这个名称必须是.gitignore），否则不会起作用
有就读取内容，且只会一行一行的读取，所以对应名称不要写在一行，否则会当成一个整体
即上面基本都是一行一行的写，其他*代表着所有，即所有是某某.iml的，都会忽略，即不添加
当进行.gitignore文件读取后，然后再去根据L配置文件和P配置文件操作
当然了，对应文件的操作，只会再对应时候起作用，比如.gitignore文件只会操作添加
P配置文件操作文件提交和添加，修改，删除的最终位置，当然也操作A分隔符和B分隔符
L文件决定添加，修改，删除方式，比如提交后，显示或者添加不会进行，却可以直接的修改和删除
一般会先看.gitignore文件，然后L配置文件，然后P配置文件，都有各自作用
而正是因为只会找工作区的.gitignore文件，所以我们删除对应工作区的文件时，就不会起作用了
而正是因为这样，一般我们都会将他的信息存放在本地仓库里，使得可以被还原
一般在工程初始化时，都需要提前准备好需要忽略的文件列表
在这里提醒一下：实际上可视化界面的操作，本质上也是操作命令，只是方便许多而已
分支管理：
几乎所有的版本控制系统都以某种形式支持分支
使用分支意味着你可以把你的工作从开发主线上分离开来进行重大的Bug修改、开发新的功能，以免影响开发主线
在开发中，一般有如下分支使用原则与流程：
master （生产） 分支：
线上分支，主分支，中小规模项目作为线上运行的应用对应的分支
test（测试）分支：
从master创建的分支，一般作为测试部门的测试分支，进行预发测试
测试完成后，需要合并到master分支，进行上线，中小规模项目可省略此分支
develop（开发）分支：
从test创建分支，如果开发没有test分支，是从master创建的分支，一般作为开发部门的主要开发分支
如果没有其他并行开发不同期上线要求，都可以在此版本进行开发
阶段开发完成后，需要是合并到test分支继续测试，如果没有test分支，可直接合并到master分支
hotfix(bugfix)分支：
从master派生的分支，一般作为线上bug修复使用，修复完成后需要合并到master、test、develop分支
上面一般都是这样的创建分支，实际上无论是什么分支都可以创建，且可以创建多个分支
只是上面的名称一般这样写，可以见名知意
查看分支：
查看分支使用 git branch ：
git branch
git branch -v
git branch -av
注意：在 git branch 的输出内容中，有一个分支，前面带有 * 号，这标识我们当前所在的分支
其中显示的* master实际上是当前文件状态，所有加上-v时，后面出现的7位数
就是对应的回退文件的简写名称，再后面就是对应的说明内容
创建分支：
当我们要修复一个 Bug，或者开发一个新特性，甚至是在初学的时候怕打乱原来的代码
都可以新建一个分支来避免对原来代码的影响
git branch dev
切换分支：
当我们创建完分支以后，我们需要切换到新建的分支，否则，所有的修改，还是在原来的分支上
事实上，所有的改动，只能影响到当前所在的分支
git checkout dev
注意：当我们进行状态的切换时（也就是状态改变）
那么对应的分支信息的状态信息就会改变（只有回退文件的信息，对应暂存区的不会)
即暂存区是共享的，回退文件是不共享的，但可以使用git reset --hard "对应ID"使得在同一个状态
显示的时候，会根据L配置文件的信息来显示，即显示这个分支的回退文件，且会显示这个回退文件的所有归属，按照归属顺序来
但所在的归属是占第一位
如HEAD -> （当前的归属），master，第一个归属，第二个归属，…，若当前归属是master，那么后面就直接按照顺序来
但其他的分支不会，因为分支是互不影响的
通过实验我发现，在不同的分支，提交的状态信息，只会服务于这个分支（只是提交，其他的共享），其他分支并没有这些信息
那么就可以说，每个分支，都有对应的回退文件
但是若是在一个分支下创建分支，那么创建的分支会有对应的状态
即回退文件会给子分支，即子分支当场就有他父分支的当时状态
当我们操作git log命令时，就会显示出当前的状态，可以知道的确是给予了子分支
我们可以通过git reset --hard 对应名称，使得这个分支的状态变成回退文件的状态
即他们的状态是可以发生改变的，从这里我们发现，他们都是一些状态的存放，即每个分支都会有对应的状态信息
那么也就是各自都有对应的文件信息，且他们都有一个共同的文件
按照前面说的maven的工程来说，可以将这些分支划分为各自的子工程来操作，拥有共同的文件（父工程）
即他们可以操作本仓库的对应部分代码
在大型项目中，可能本地仓库也是得到对应项目的分支，且这个分支也足够大（前面说过类似的）
即我们也需要再本地创建分支来操作，而不使用主分支
即也是防止在主分支操作代码时，出现问题，或者思路错了，代码突然回不去了（一般都可以回去，只是防止而已）
主要是出错不好维护，分工明确的好维护
创建并切换分支：
git checkout -b dev
这个命令合并了前两个独立的命令（即git branch dev命令，和git checkout dev命令，依次执行），平常使用中一般这样使用
注意：git checkout好像也可以进行还原，经过测试，若分支名称与要还原的文件名称相同，那么只切换分支而不会还原，若要进行还原就需要这样的操作，git checkout – aa，aa是对应的文件，这样就不会进行切换了
合并分支：
当我们修复完成一个 Bug，或者开发完成一个新特性，我们就会把相关的 Bug 或者 特性的上修改合并
回原来的主分支上，这时候就需要 git merge 来做分支的合并
首先需要切换回最终要合并到的分支，如 master ：
git checkout master
git merge dev
合并回主分支的时候，后面可能会面临到冲突的问题，注意合并的是对应回退文件对应的文件信息
如他们都对a.txt操作，且同一行的对应数据不同，那么在合并时，会出现冲突，发生冲突后，就会出现如下图显示：
对应文件：
本地仓库显示对应文件名称，即a.txt的名称是a，若是远程仓库则显示对应文件所在的状态ID
代表着2和1是冲突的地方，在同一行
上面的both modified代表这个文件是冲突文件，没有git status -v的简化显示
就不可以提交或者切换分支了
已经操作对应冲突文件，一般只能进行回退了
当然也可以使用git add ./或者git add .这两个都表示添加当前工作区全部文件（当然目录也算），或者普通的添加来实现提交
目录也可以指定名称，或者名称/，都是一样的
我们使用touch ./时，并不会创建文件，windows也不允许创建./的名称文件
这里我们使用git add ./（当然其他的添加也可以）命令，就会出现如下：
我们会发现On branch master下面的内容不一样，没执行git add ./时，说明出现冲突，而执行后，就说明冲突已经修复了
一般我们在执行git add ./前，会对上面的文件进行改动，如：
这时虽然冲突已经修复了，但是他任然在进行合并的操作，即我们还需要进行提交：
但是我们发现，当我们进行提交时，他提示，在合并时不能执行部分提交，所有我们要进行全部提交（分支自然是全部合并的啊，否则比较麻烦，所以为了进行约束，我直接不给你部分提交）
即git commit -m l，不指定对应文件，但他只会提交A分隔符的文件，即B分隔符不会提交，对应状态一般都对应当前文件状态
当没有A分隔符时，相当于git status
那么就会有这个状态了
若你是执行git add ./后对上面文件进行改动，那么再次进行git status时，可以发现如下：
当我们进行git commit -m l命令操作时，由于只能操作A分隔符，那么对应的B分隔符还在，所有我们也可以再次提交
当再次合并时，会提示已经是更新的了
根据内容来的，而不是时间来的，即最开始就是最新的，除非改变覆盖的对方的状态内容，如上面的dev
相当于当前分支被他覆盖
但是要注意：在进行分支切换时，若当前分支已经改变了对应提交过的文件
那么就不能进行分支切换，除非提交或者回退（checkout）以及合并操作
虽然暂存区是共享的，但合并操作不能使得暂存区有文件，否则报错
在前面我们知道checkout不止可以使得修改和删除进行回退，也可以操作分支切换
若对应文件与已经存在的分支是一样的话，那么操作的就是分支，否则就是操作文件
最后：可能你会出现特殊情况，即明明冲突的代码却在没有进行强制覆盖时进行覆盖了
这是因为被覆盖的文件只是提交了，但没有进行改变（手动改变，合并也不算改变），即在没有改变时，默认强制覆盖
当你改变这个文件时，那么就会是普通覆盖了，即会出现冲突
这里说明一下，由于windows和linux的系统是不一样的，即windows打开文件操作数据，和linuc的vi或者vim打开文件操作数据
对应一般都不会相同，所以可能vi或者vim添加的数据，在windows里显示的是乱码（一般是编码不同）
但windows的却可以在linux里正常显示，那么也可以说windows的编码是linux的编码的扩展版
但这时，我们发现，虽然提交成功，但出现了如下提示：
出现了两个提示，一般我们在没有修改时，只会显示一个提示，这个提示
是因为不同操作系统下，处理行尾结束符的方法是不同的：
如Windows下：使用回车（CR）和换行（LF）两个字符来结束一行，回车+换行(CR+LF)，即"\r"和"\n"一起的操作
而Linux：只使用换行（LF）一个字符来结束一行，即"\n"
所以上面的提示表示，正在被CRLF替换，然后显示在windows里面
所以一般我们在添加时，就会进行转换一次
提交时，输出一次，交给windows，即不管有没有对应都进行转换，即相同的变相同的
因为这是到真正的文件，所以这里就强制了转换
若在添加后，再次进行操作数据，提交操作得到时，也会进行转换，但输出不管有没有正确都进行转换，所有出现了两次
删除分支：
当之前创建的分支，完成了它的使命，如 Bug 修复完，分支合并以后，这个分支就不在需要了，就可以删除它
git branch -d dev
注意：由于分支是互不影响的，一般的创建分支除了状态的给予，其他操作基本一样，即分支也可以删除分支，但不能删除本身
如分支可以删除对应的master分支（我们通常默认一个主分支，这只是默认的认为而已，实际上作用与其他分支是一样的）
但不建议这样操作
那么到这里我们可以说Git是可以操作文件的对应时间的文件，在中途可以修改（暂存区），还可以还原（回退文件）
最后也可以操作部分（分支）
但他们也只是自己进行操作，若要使用共享，需要一个别人基本可以随时访问的仓库，也就是远程仓库
所以接下来我们来说明以下远程仓库
Git远程仓库：
添加远程库 ：
现在我们已经在本地创建了一个Git仓库，又想让其他人来协作开发，此时就可以把本地仓库同步到远程仓库
同时还增加了本地仓库的一个备份
那么我们如何搭建Git远程仓库呢，我们可以借助互联网上提供的一些代码托管服务平台来实现，其中比较常用的有GitHub、码云等
GitHub（ 地址：https://github.com/ ）是一个面向开源及私有软件项目的托管平台
因为只支持Git 作为唯一的版本仓库格式进行托管，故名GitHub
码云（地址： https://gitee.com/ ）是国内的一个代码托管平台，由于服务器在国内，所以相比于GitHub，码云速度会更快
接下来我们演示如何将本地仓库中的代码同步到github（英文界面的Git远程仓库），和码云的操作基本一模一样
注册GitHub：
注意：你的操作界面会可能有所不同（不同时期的github），但步骤大致相同
第一步：登录网址，点击sign up注册账号：
第二步：填写信息，注意邮箱要真实有效：
验证操作不一定是上面的
第三步:直接点击join a free plan（免费加入）：
第四步：直接划到最下面点击complete setup（完整安装）：
第五步：邮箱需要验证，验证完成后登陆进github：
跳转页面后：点击skip this for now：
接下来就可以登录了
创建远程仓库：
点击"create repository"按钮仓库就创建成功了
同步远程仓库：
Github支持两种同步方式"https"和"ssh"
在程序中，http好像不可以，因为虽然是一个"s"的差别
但实际上对应的端口操作可能不同（http操作80端口，https操作443端口）
操作的协议内容可能不同，操作的客户端到服务器的连接也可能不同，所以也是有区别的
若要实现http，可能需要对Github进行操作，具体可以百度，但我们一般操作https，所以以https为主
如果使用https很简单基本不需要配置就可以使用
但是每次提交代码（好像不支持了）和下载代码时都需要输入用户名和密码（远程仓库用户名和密码）
而ssh则根据身份来决定，即公钥加密和私钥解密对应身份相同来决定，若是则可以连接
而且如果是公司配置的私有git服务器一般不提供https方式访问，所以我们要来着重演示"ssh"方式
ssh协议：
什么是ssh?
SSH是英文Secure Shell的简写形式，通过使用SSH，你可以把所有传输的数据进行加密
这样"中间人"这种攻击方式就不可能实现了，而且也能够防止DNS欺骗和IP欺骗
使用SSH，还有一个额外的好处，就是传输的数据是经过压缩的，所以可以加快传输的速度
上面是对应情况
注：使用SSH同步方式一般需要双方各自配置密钥
密钥是加密和解密的总称，即也可以叫做公钥或者私钥等等别名
为什么需要对应的密钥：
首先我们是知道ssh是进行加密的，而这个加密，就需要一个方式来加密，若客户端和服务端都使用密钥
那么就要知道，对应的密钥一定要是一样的，即进行我们的加密和解密过程需要一致
以登录为例子：
当我们进行登录时，首先加密自己信息，然后服务器解密对应信息，使得登录成功
但是客户端是非常多的，服务器不可能有多个密钥，且就算有，在庞大的时候
密钥也是容易泄露的（虽然很难，因为是自己内部的，即基本不能被拦截，所有我们基本考虑服务器是否有多个密钥）
由于是对称加密，那么数据也就是会泄露
所以就出现了新的形式，公钥和私钥（都是密钥的别称）
公钥加密后的密文，只能通过对应的私钥进行解密。而通过公钥推理出私钥的可能性微乎其微
为什么是这样呢，可能会有疑问，为什么不是公钥来解密公钥，而是私钥来解密公钥呢
这是因为在创建时，实际上我们将密钥的两个功能进行分开，即公钥只有加密，而对应的解密过程放在私钥里面
所以我们一般将公钥和私钥称之为不对称的加密，而密匙就是对称的加密
而由于这个公钥和私钥都在服务器，客户端没有进行存放，以登录为例子：
当我们客户端去访问登录时（一般不会发送密码，而是用户名，防止拦截），首先是进行获取公钥
服务器会给出公钥给我们客户端（这个拦截也是没有用的，因为推断不出私钥，那么就不能解密）
让我们使用这个公钥对密码进行加密（一般我们手动进行输入，或者对存在的密码，但没有提交的自动进行加密）
当再次发送数据时（一般都会是重定向，且这个已经加密了，所有拦截也基本没有用）
服务器的内部私钥进行解密，然后登录成功，这样就解决了客户端多的问题
但是我们知道，公钥是服务器来发送的，而我们的请求是可以被拦截（中间人攻击）
假如发送给我们的公钥不是对应服务器的公钥，而是陌生的公钥
那么当你加密时，由于基本会再次发送数据（一般都会重定向，他给出的地址）
那么当他使用私钥进行解密时，就获取到你的数据了
这一点与在分开存放的两个密钥是不足的一点，虽然分开存放的两个密钥客户端多是一个问题
但是当拦截后，也是不知道如何破解的，基本很难被破解，因为不知道你的密钥形式
那么有什么办法可以解决这样的情况呢，看如下：
首先分析问题，由于拦截基本不可完全避免，那么我们就需要判断公钥是否是对应服务器的公钥
一般的ssh在得到公钥时，会让你进行确认，当确认后，就会使用这个公钥，但反复的确定是非常麻烦的
这虽然也是一个好处，但不实用，因为需要反复确认
我们也可以进行如下操作：
那么我们也可以给我们客户端添加公钥和私钥
那么当我们请求时，可以发送这个公钥过去（包括用户名，一般是这个），放在服务端，但是这个就与之前的一样了，所以这个不会操作
或者首先将公钥放在服务端（这里是这样），然后请求时直接发送用户名
然后再次进行一次真正的登录访问
这时服务器会使用你的公钥进行加密，然后返回，你再使用私钥进行解密
然后使用特殊的加密方式（如MD5）加密，使得服务器也可以进行解密（MD5，他只有公钥），我们发现，我们将对应公钥存放再对应服务器里
私钥存放再客户端里，即这个公钥由我们自己使用，而不是得到别人的公钥，那么为什么不直接使用MD5进行加密和解密呢
而正是由于MD5是普遍的，即有对应的key-value，所以我们需要一个自己的扩展MD5的数据，也就是公钥和私钥，即密钥操作
那么每次操作时，服务器都会使用公钥加密一个随机数，随机数是生成的
使用随机数，可以使得更加的难以破解，防止密码非常容易而被反向破解（找key-value库等等）
虽然这里随机数加密数据也会拦截获得（但对应的库却可能没有合并的value，因为也合并了密码了）
然后你通过自己的公钥进行解密，使用MD5和解密后的数据（随机数）以及密码进行加密，最后在服务器
他也通过对应用户密码和MD5和先前的随机数进行加密，比较是否一样（因为MD5基本不能反向破解的，所以就进行比较）
若一样登录成功
实际上算你发送的公钥被拦截了，他也基本破解不了，但是他是可以拦截服务器的响应的
所以服务器一般会使用你的公钥进行加密，然后你自己使用私钥进行解密，然后再通过，MD5来进行互相的操作
而正是因为MD5使得输出的密码基本破解不了
特别是加上密码的MD5加密,，拦截一般不可以拦截加密的随机数，即得不到对应密码的MD5加密的密码，简单来说，由于公钥一开始在对方那里，那么就形成了全程加密，而为了使得md5更安全，使得被黑客也同样使用md5进行破解，就通过第一次公钥加密保留加盐的信息，这样就完成了ssh的安全作用
我们发现原来是服务器发送公钥变成了客户端发送公钥，这样就能保证我们的公钥不会是其他的服务器了
假如他拦截我们的公钥，将自己的公钥发送到服务器，然后再返回，而由于对应公钥和私钥不同
那么对应的随机数的解密基本是不一样的，或者会出现保存（一般不会），那么一般就会显示登录失败
而由于我们使用这个与之不同的随机数加密密码的，那么他也基本破解不了
我们发现，前面的是得到服务器的公钥加密和服务器的私钥解密（这个服务器可以是中间人），拦截客户端
变成了得到客户端的公钥加密和客户端私钥解密（但正是因为需要真正的访问，即后续还要有MD5真正的操作密码）
由，加变成解和加
即他们只能拦截服务器，而由于服务器基本不会操作密码给出，即基本获取不到密码
实际上就算密码的对应给出，而出现这样的情况的
所以就解决了对应被拦截的风险，现在的ssh也基本是这个操作，公钥放在服务区，私钥放在客户端
所以我们也发现，只要有双向的加密和解密，基本都不安全，而只有一向的基本都很安全（MD5），前提是对方存在了你的公钥
具体也可以参照这个博客：https://blog.csdn.net/Eliauk22/article/details/122595452
ssh密钥生成：
在windows下我们可以使用 Git Bash.exe来生成密钥，右键菜单打开Git Bash
git bash 执行命令，生成公钥和私钥
命令：
ssh-keygen -t rsa
上面有个y的选项，是因为我之前创建了一次，他提醒我是否覆盖，一般的第一次是没有这个选项的，即直接回车就可以了
否则是需要操作这个选项的
执行命令完成后，在window本地用户.ssh目录，即C:\Users\用户名\ .ssh下面生成如下名称的公钥和私钥：
再次说明一样，私钥和公钥也是密钥的一种，只是他们是密钥的部分操作，即将密钥的加密（公钥）和解密（私钥）分开了
之所以生成两个，一个是给服务器的公钥，一个是自己进行解密的私钥
ssh密钥配置：
密钥生成后需要在github上配置密钥，本地才可以顺利访问
在key部分将id_rsa.pub文件内容添加进去，然后点击"Add SSH key"按钮完成配置
即公钥内容是刚刚公钥文件里的内容，根据前面的分析，一般公钥需要放在服务器的
实际上也可以放在访问对象里，即GitHub远程仓库，使得我们进行解密，然后加密发送
远程仓库的操作：
查看远程仓库：
如果想查看已经配置的远程仓库服务器，可以运行 git remote 命令，它会列出指定的每一个远程服务器的简写
一般的使用git init是不会显示任何内容的
如果已经克隆了远程仓库，那么至少应该能看到 origin ，这是 Git 克隆的仓库服务器的默认名字
这个命令可以在后面添加远程仓库操作后，再次使用看内容
添加远程仓库：
如果已经有了一个本地仓库，然后打算将它发布到远程，供其他人协作，那么使用：
git remote add origin your_remote_git_repo
上面说明了，拉取（fetch）和推送（push）操作的地址，即可以使用这个别名进行拉取和推送，一般都是这样
推送本地的内容到远程仓库（要有关联才行）：
当本地仓库中，代码完成提交，就需要将代码等推送到远程仓库，这样其他协作人员可以从远程仓库同步内容
git push -u origin master
git push origin master
注意： git push -u origin master ，第一次使用时，一般都会带上 -u 参数
在将本地的 master 分支推送到远程新的 master 分支的同时，还会把本地的 master 分支和远程的 master 分支关联起来
如图（下面是推送原样的状态）：
即我们可以直接使用git push来进行操作，因为它会自动指向关联的地址（这里就是jj）进行推送
而一般不是原样的状态，则如图：
最后说明一下，我们在前面说过，远程仓库的改变会使得推送不了，即需要拉取
那么我来说明一下，为什么会推送不了：
一般的我们操作代码，基本都是正确的进行提交，那么就基本不可能出现提交以前的代码
即git规定，只能推送新的文件
那么在这样的情况下git会根据文件的最新情况，当git远程仓库不变时，假设他为空的
这时我们推送一个a文件，再次推送一个b文件，那么远程仓库的最新文件就是b文件的这时的状态（回退文件的信息）
这时这个回退文件包含两个文件信息
但要注意，一般我们通常都在一个仓库里进行，不同仓库推送和拉取都不能操作的
除非强制推送和拉取（没有最新的限制，因为拉取就是最新的）
若我们使用git reset --hard 对应a文件的状态ID，那么这个对应的时间，一点是低于b文件对应的时间，即可以说是老版本
而老版本是不能推送到比他新的版本的，而正是因为推送的是状态，所以推送一般要小心的进行
当然与不同分支操作一个文件一样
不同的本地仓库操作一个远程仓库的同一个文件也会出现冲突，这个后面会说明远程仓库的冲突
如何确定不同的本地仓库
若本地仓库不变，而修改远程仓库，那么远程仓库的状态，一定比本地仓库状态要新
也就是说，本地仓库相当于是老版本了，也就不能进行推送了
那么这时，我们就需要拉取，将对应最新的版本获得，使得可以进行推送（推送的冲突一般是版本问题，通常解决冲突的情况在拉取，由于版本问题，所以推送基本是没有什么解决在代码或者文件的冲突了）
所以再推送之前，需要先pull（拉取）远端仓库，因为如果发现提交版本不一致的话，就会出现错误
注意：我们推送的是远程的服务器，那么就一定要联网的，否则对应数据过去不了，推送后，返回的是服务器的响应数据
最后我们在使用https进行推送时，现在基本不支持用户名和密码进行验证了，而是需要一个访问令牌，当然ssh是可以的，也就是说令牌相当于用户名和密码，经过ssh来进行操作
但我们通过服务器来获得一个数据（一般是字符串），一般的我们称这个叫做token，就如cookie类似的进行判断
比如登录来说，cookie使用键值对，匹配key，的value是否一样，若一样则登录
而token直接发送value，然后只要你有一样的value那么就登录，但这里可以发现，token说只要有一样的就可以登录
实际上他并不是自动携带的，不像cookie一样会自动携带，即只要你知道服务器的token，那么就可以进行登录
而由于不会自动携带，那么被拦截基本获取不了
而这个令牌创建方式如下：
注意：可能显示位置会不同（不同时期的github），但点击的按钮基本是一样的
第一步：点击Settings（设置）：
第二步：点击Developer settings（开发者设置）：
第三步：点击Personal access tokens（个人访问令牌）：
第四步：点击Generate new token（生成新令牌）：
第五步：给token起一个描述名字（随便起，且基本必须要起名，否则不让你创建）：
第六步：设置token多久后过期
这一步可以不操作（所以有个*号），一般默认30天，但最好设置最低的7天
因为token如果被获取，那么他就能够登录进去，所以设置低，越安全：
第七步：设置token拥有的权限（一般都设置如下操作，使得可以推送，否则推送时，会失败）：
第八步：点击Generate token（生成令牌），生成一个token：
最后说明一下，我们生成令牌后他基本只会显示给你看一次，即这时我们就需要重新生成令牌了，但不是进行删除对应的token
而是更新对应的token，即是重新生成令牌代码，如当我们点击上面的生成令牌时，如图所示（下面是我的测试操作）：
ok，当我们进行刷新页面时，如图：
这时，就需要我们点击"222"进入看一看了，如图：
对应的翻译是，如图：
我们点击重新生成令牌：
所以前面说过，重新生成不是删除token，而是更新token，这里也可以重新设置天数，当然，默认的任然是30天，更新后，如图：
我这里是：
之后再次刷新，那么任然需要重新生成，即他只会显示给你看一次
那么我们可以通过这个令牌来使用https访问操作了，对应的代码如下：
使用上面的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（实际上我进行了改变，这只是测试）进行操作：
git remote add j https://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@github.com/wobushigoudao/repo1.git
git remote add j https://github.com/wobushigoudao/repo1.git
那么一般在你不删除github的令牌情况下，基本就可以推送了（设置了对应权限）
若没有对应的令牌代码，那么就是普通的需要用户名和密码的访问，但是不支持了，所以最后一般推送不了
最后我们回顾git merge，一般的，我们都会加上分支的名称，若是不加名称的呢，他可能会尝试并合并其上游分支（即远程分支）
但通常情况下基本都是会报错，即需要指定分支，下面的拉取操作里会说明什么时候用到
对应最新的状态，接下来我们说明一下拉取操作：
从远程仓库获取最新内容：
与推送一样的是，拉取虽然可以不是得到最新（自己所在状态的不会进行拉取）
他们两个都必须是在同一个仓库里进行（不是同一版本）
在多人协作过程中，当自己完成了本地仓库中的提交，想要向远程仓库推送前，需要先获取到远程仓库的最新内容
可以通过 git fetch 和 git pull 来获取远程仓库的内容
git fetch origin master
git pull origin master
git fetch 和 git pull 之间的区别：
git fetch 是仅仅获取远程仓库的更新内容，并不会自动做合并，即当我们在远程仓库创建改变一个文件时，使用git fetch命令
那么对应的远程分支就会出现在本地仓库，上面使用origin别名
那么接下来就需要使用git merge origin/master（对应分支）来进行合并，合并对应远程分支操作
可以使用git branch -a来查看，会发现出现了红色的remotes/origin/master，下面是我的测试：
红色是远程分支（通过别名确定，若删除别名，那么这个分支也就没了）
也相当于在进行拉取时，本地仓库创建一个对应分支来获取拉取的数据，且隐藏起来
而推送就是把指定分支给对应远程仓库的相同分支，没有则创建获取，拉取是指定合并当前分支，推送是去合并对应分支
一个是当前（唯一，拉取），一个是目标（也是唯一，推送）
要使用git branch -a才可看到，注意：当我们没有aa这个分支时，若直接切换
那么他默认从远程分支后面的相同aa分支（若工作区有aa文件，则会报错）
创建一个aa分支出来，然后切换，若没有对应的aa，那么就没有创建
即没有aa分支，所以切换就会与普通切换一样的出现没有切换时的错误
当切换时，aa分支相当于是到下面的remotes/j/aa分支创建一个aa分支
所有像这样的由远程分支创建的分支操作我们一般将remotes/j/aa分支叫做aa的上游分支
所有前面说的无参的git merge就是默认合并上游分支
我们在aa里进行操作，那么就是合并remotes/j/aa分支，其他没有上游分支的就会报错
我们也可以使用git checkout j/aa或者git checkout remotes/j/aa来切换到远程分支，显示如下：
出现了一个隐藏的指向了，实际上就是指向j/aa（游离状态指向）
是因为远程分支我们不可显示的指向，所以就是特殊隐藏的指向
即remotes可以看成远程分支，我们要合并的就是后面的origin/master
注意，前提要先拉取这个远程，才可有origin/master，直接的git branch只能查看本地分支，即查看不了远程分支
git pull 在获取远程仓库的内容后，会自动做合并，可以看成 git fetch 之后 git merge
也就是说上面的git fetch origin master 和git merge origin/master一起操作了
拉取就与使用git merge命令差不多，也是合并操作，那么也会有冲突了
注意：远程仓库之间不能进行切换，切换只能是本地与远程之间的操作，但合并却可以
像不能在同等分支之间切换且真正存在的分支，我们称之为游离状态分支
注意：这些分支指向的是本地仓库，也就是说，操作他们也就是操作本地仓库
不要觉得我们操作他们就是操作远程仓库，实际上他也是一种分支
只是有远程标签而已，而正是由于有远程标签，那么我们在回退时，虽然可以到对应文件位置，但他分支信息并不会出现
发现并没有过来，即指定这个回退文件
再次强调一点，分支是对应的存放状态的，所以一般可以回退任何文件信息
移除无效的远程仓库：
一般的，git bramch -d "对应分支"命令，只能删除没有远程标签的分支（即本地分支），而要删除远程分支，需要如下操作：
如果因为一些原因想要移除一个远程仓库：
git remote rm 对应的别名
注意：此命令只是从本地移除远程仓库的记录，并不会真正影响到远程仓库，实际上被拉取后，就是一个新的分支了
只是这个分支有远程标签，使得被隐藏
从远程仓库克隆：
如果你想获得一份已经存在了的 Git 仓库的拷贝，这时就要用到 git clone 命令，
Git 克隆的是该 Git 仓库服务器上的几乎所有数据（包括日志信息、历史记录等），而不仅仅是复制工作所需要的文件
当你执行 git clone 命令的时候，默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来
如果你本地没有仓库，希望从已有的远程仓库上复制一份代码，那么你需要 git clone
git clone https://github.com/lagou-zimu/repo1.git
git clone git@github.com:lagou-zimu/repo1.git f
注意： git clone 后面的仓库地址，可以支持多种协议，如 https， ssh 等
很明显，克隆是最好的拉取方式，因为完全的是拉取过来的（但是他确不能保留已经操作的代码，因为并不操作拉取后的合并，而是直接的总体覆盖，相当于删除后添加他），在实际操作中，我们第一次大多数都会这样，虽然以后也可以，但是比较慢
从远程仓库中拉取：
拉取 pull：
git pull 远程仓库名称（别名) 分支名称
最后要注意：无论是推送还是拉取，对应的仓库一定要是一致的
解决合并冲突：
在一段时间，A、B用户修改了同一个文件，且修改了同一行位置的代码，此时会发生合并冲突
A用户在本地修改代码后优先推送到远程仓库，此时B用户在本地修订代码，提交到本地仓库后，也需要推送到远程仓库
此时B用户晚于A用户推送，故需要先拉取远程仓库代码，经过合并后才能推送代码
在B用户拉取代码时，因为A、B用户同一段时间修改了同一个文件的相同位置代码，故会发生合并冲突
A用户：修改a.java代码推送到远程仓库：
B用户：修改a.java同一行代码，提交之后，推送代码后出现冲突：
解决方法：
先拉取代码（下面是冲突的代码）：
若出现代码冲突，则再打开代码解决冲突
前面说过了一样的操作，即拉取后出现的代码在上面进行操作，然后进行提交
我们就可以推送了（新的版本，且解决了冲突，一般我们将包括的不在同一行就可以了，即删除包括的也可以）
最后注意：当我们克隆后，拉取基本是不会进行真正的拉取了
因为若远程仓库不变，当然不会拉取，若变化了基本与当前仓库状态一样，即基本不会拉取了
而推送就需要更新对应状态推送，而推送后，远程状态就与自己一样了，不推送，对应远程仓库不变
当然推送不更新的也是不会推送了
即他们都不操作时，会出现提示Already up to date（已更新）
小结：
远程仓库操作常用命令：
git remote
git remote -v
git push origin master
git clone https://github.com/lagou-zimu/repo1.git
git pull origin master
最后说明：不同窗口，上下键的历史命令也是相同的，因为git自带的设置，窗口之间的命令历史记录共用
且拉取时，若没有相同的历史记录，那么也不能拉取
注意：冲突时（无论是本地还是远程），那么一般对应符号在冲突的那个位置
如果出现了不同的位置，或者明明有些是正确的但是还是出现了冲突
可能是因为数据不完整性，你可以全选进行复制，来进行操作，那么基本就不会出现特殊问题了
且也要注意提交后的文件要进行手动改变，否则也会是强制覆盖
在Idea中使用Git ：
在Idea中配置Git：
安装好IntelliJ IDEA后，如果Git安装在默认路径下，那么idea会自动找到Git的位置
如果更改了Git的安装位置则需要手动配置下Git的路径。选择File→Settings打开设置窗口
找到Version Control下的Git选项：
点击Test（测试）按钮，弹出下面的框框，表示现对应路径正确，配置完成
有些高版本idea不会弹出框框，而是在对应路径下面显示提示信息
开发中idea的Git常见操作：
初始化并提交项目到远程仓库 ，项目leader操作（也就是最开始的框架搭建的操作，一般是公司第一个程序员进行的操作）
执行步骤：
在GitHub/码云中创建远程仓库
将maven工程交给Git管理
配置忽略文件
提交到本地仓库
推送到远程仓库
执行过程：
在github中创建远程仓库
将maven工程交给Git管理（有些idea版本位置可能不一样，一般是新的版本）：
注意：创建的时候，最好是点击当前项目的上一级，也就是当前项目要放在工作区里面
配置忽略文件：
实际上他设置的只是idea的忽略文件，也就是从根源上对文件忽略，而不是在添加在工作区里
且这个是全局设置，即其他项目也会忽略看不到
添加到暂存区（在对应项目或文件上右键出现，可以发现Git选项）：
注意：只要是在工作区里的文件，基本都可以看到Git选项，否则看不到
然后进行提交：
点击Commit提交到本地仓库
若出现对应的提示警告，一般都是代码中右边的提示造成的，但基本可以忽略
所以我们基本可以不用管，继续点击提交（Commit）即可
推送到远程仓库（点击VCS）：
只要有Git选项里，基本都有Push选项，找一找即可
创建远程信息和别名后，我们再次点击Push就可以提交了
克隆远程仓库到本地（开发人员，不是最开始初始化的操作，一般我们都是这种）：
操作步骤：
从远程仓库克隆：
首先我们关闭项目：
然后进入下面的界面
一般的没有打开过项目就是下面这个界面，或者设置关闭不自动打开项目，那么关闭idea后也是下面这个界面
idea要求他是空文件夹，这时idea的操作，而不是Git的操作
当然，也可以直接的D:\a，如果没有a，那么就会创建a（idea的设置）
我们打开项目时，可以指定该项目文件夹或者该项目的pom.xml都可以打开对应项目并为他创建工作区间
本地仓库常规操作（开发人员、重点）：
新增文件：
在ssm_dao模块中，新增一个GitMapper接口，新文件状态红色，未进入暂存区：
加入git之后，红色变绿色，已经进入暂存区（且在B分隔符里也有，相当于创建新文件，然后也进行修改了，即添加数据）：
然后就可以进行提交了
编辑文件：
在ssm_dao模块中，修改GitMapper接口，文件变蓝色
正常编辑的文件默认放在暂存区，不需要再添加到暂存区
然后就可以进行提交了：会出现如图所示：
看最下面，我们发现，出现了两个窗口，可以知道左边是原来的文件数据，右边是进行修改的文件数据
即提交后就是右边的数据了，这里给出变化给你看
看最上面，发现显示了对应暂存区的文件路径
重置文件到修改前：
比如修订了某一文件，需要重置到修改文件之前的状态，选择文件，右键菜单：选择Git—>Rollback
重置后，文件颜色自动消失，说明已重置到修改之前的状态，相当于使用git checkout "对应文件"来操作回退
然后可以发现，对应添加的数据也就消失了（idea在这时会自动更新）
提交到本地仓库（会显示对应暂存区的文件）：
注意：推送时，可能会出现部分文件没有推送，一般的这样的情况很少，但对于大项目来说会
一般可能是不会识别，另外一种就是他出现了某种错误（试着局部推送，或者重新推送）
还有一种就是文件太大，忽略过去了（一般是这一种），但是大多数的情况下，不会出现没有推送的情况
因为无论什么情况（程序），基本都可能会出现小差错的
本地仓库推送Push至远程仓库：
操作步骤：
推送前一定要先拉取远程仓库对应分支
如果有冲突，先解决冲突，并提交到本地仓库
推送当前分支到远程仓库
操作过程：
推送前一定要先拉取远程仓库对应分支
注意：拉取和推送是状态之间的操作，与暂存区无关
若拉取时出现了Update canceled，一般是网络不好的原因（因为文件过大），可以多实验几次，就基本可以拉取了
如果有冲突，先解决冲突，并提交到本地仓库：
点击Merge（合并）…然后出现（我测试的代码）：
上面分为左框，中框，右框
其中左框是我们的代码，右框的远程仓库的代码，中间是要进行合并的代码
一般的他会给出一个合理的代码出现，但我们可以进行手动操作，我们可以看到上面两个x和>>，这两个符号，点击X代表不进行合并
一般的，我们要拉取，那么通常点击右框的<<符号
他会进行合并操作（这一行覆盖），然后点击左框的>>符号（这时会变成右下的>>符号，代表放在后面），再次进行合并
当然无论是从右框开始还是左框开始，都是可以的
只不过我们习惯与右边开始，因为我们是拉取右边代码，所以要先人右边进行合并
若是先点击左框，然后右框，那么就是如下，然后就出现了：
否则出现：
注意：我们在git时，一般操作完毕后，需要手动的提交以下
而idea会自动的帮我们提交，所以我们再次提交时，会提示没有提交的文件（即暂存区没有文件）
然后进行推送即可
分支操作：
操作步骤：
创建分支
切换分支执行操作
执行合并操作，master合并dev
操作过程：
可能对应界面不同，因为我们不是同一个idea版本
创建分支
一般的，我们操作Git时上面的VCS可能会变成Git，我们也可以进行调回来
一般我们只要将当前项目放在Git的工作区里，他VCS就会默认从< none>（默认的就是VCS）变成Git
如果这时我们删掉对应的.git，那么虽然他们都是红的，但基本什么都不能操作
若在Git里使用VCS，那么会有如下：
其中*号代表主要分支，标签符号代表当前所在分支，这里就是即master（由于是主要的，那么颜色要深一点）
我们可以看看这个图片：
发现其他的不是主要的分支是没有符号的，而对应的当前的标签就是颜色浅一点的符号标签
其中普通分支放在中间，远程分支放在下面，上面的就是创建分支了
无论使用那种方式，最后都会到如下框框：
这里创建一个dev分支，点击创建
其中默认勾选的Checkout branch表示我们创建后，就切换到创建的分支，相当于git checkout -b dev
切换分支执行操作：
发现选择哪个分支，那么就有浅色的*符号，其他主要分支不会变，默认一直是深色的 *（除了是当前标签）
我们点击右边的Checkout就可以进行分支的切换了，这里就切换到dev，因为是操作dev的
合并操作：
当我们要进行分支的合并时，可以操作如下：
将dev合并到master，因为我们所在的分支就是master
然后就可以进行推送了
傻瓜追踪器：版本比较 ：
对代码修改后，可以点击对比按钮，对比差异
我们可以观看历史，点击上面的Show History
然后就会出现上面的下面的操作
每个历史，右边都会有对应的原来的代码信息（对应操作的地方的信息，即局部信息，而不是全部）
当然：文件的移动git也会记录的，这里就不多说了，文件的移动可以认为是单纯的删除并添加（移动在操作系统内部中就是如此的，注意是先添加哦，简单来说就是复制并删除）
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
