Git的使用——Git 常用命令总结、Git的使用、Git 的分支、远程仓库的使用、IDEA 中使用Git
一、Git 常用命令总结
为了方便后续查找命令，故先把总结放前面，教程放后面
1、git 基本使用的命令
后续更新！
二、Git
1、git 的历史
2、git的优势
3、git 的工作区和暂存区
4、基本使用
首先要说明的一点是，这个控制台使用的语法跟 linux 系统的是一模一样的；或者说这就是一个小型的 linux 系统。
接着就是安装完以后，右键菜单会多出 GUI Here 和 Bash Here，如果没有多出这两个选项，一般重启之后就有了；其中一般使用的都是 Bash Here，这个是通过控制台界面操作。在哪里点击右键，就会以当前文件夹目录为基准，后续的所有操作都会在当前文件夹目录下操作。
a、配置全局用户名和邮箱
git config --global user.name "xxx"git config --global user.email "xxx@"
b、初始化仓库
仓库的初始化有两种方式：一种是直接从远程仓库克隆，另一种则是直接从当前目录初始化，这里我们
主要介绍当前目录初始化，远程仓库克隆我们在后面的文章中会说到。从当前目录初始化的方式很简
单，直接执行如下命令：
git init
初始化仓库以后，当前目录下会多出个隐藏文件 .git 。如果当前目录下有项目，也就是有 .idea 文件，那么打开 IDEA ，右上角会有 Git 的操作图标。
c、查看仓库状态
git status
d、添加文件到暂存区和提交到本地仓库
（1）添加文件到暂存区
git add 命令可以将一个文件添加到暂存区，我们现在已经有一个 git01.txt 文件了，接下来，执行如
下命令将文件添加到暂存区中：
git add xxx
（2）提交到本地仓库
当文件提交到暂存区之后，此时我们可以通过 git commit 命令将当前暂存区的文件提交到本地仓
库，如下：
此时一切又恢复宁静了，没有需要 add 的东西，也没有需要 commit 的东西。
如果我们要写的备注非常多，我们可以直接执行 git commit 命令，此时会自动打开一个 vi 编辑器，我 们直接在编辑器中输入备注信息即可。
add、git commit 命令，此时系统会自动打开一个 vi 编辑器，如下：
（3）修改提交代码后的备注
提交成功之后，我们可以通过如下命令修改提交备注：
git commit --amend
运行该命令，会自动打开vi编辑器，此时我们可以重新编辑上次提交的备注信息。
e、查看提交日志
通过 git log 命令我们可以查看以往仓库中提交的日志，比如提交的版本号、提交者、提交者邮箱、
提交时间、提交备注等信息，如下：
有的时候我们要查看的命令并不用这么详细，可以在 git log 后面加上 --pretty=short ，这样显示
出来的就只是简略信息了：
git log --pretty=short
git log -p xxx
绿色的 + 表示新增的行，红色的 - 表示删除的行（当然这里没有删除的行）。
但是 git log 有一个局限性，就是不能查看已经删除的 commit 的日志.
举个例子：下班了，我发现今天下午提交的代码全都是有问题的，于是做了一个版本回退，回退到今天早上的状态，然后关机回家，第二天来了后我发现搞错了，其实那些代码都是 OK 的，于是我又想让仓库版本前进到昨天下午的状态，却发现 git log 命令查看不到昨天下午提交的版本号。此时，我们可以使用 git reflog 命令来实现这一个请求，git reflog 命令可以显示整个本地仓库的 commit , 包括所有 branch 的 commit ,甚至包括已经撤销的 commit , 只要 HEAD 发生了变化, 就会在 reflog 里面看得到，而 git log 只显示当前分支的 commit ，并且不显示删除掉的 commit。如下图
g、查看更改前后的差异
git diff
使用 git diff 命令我们可以查看工作区和暂存区的区别以及工作区和最新提交的差别。我往
git01.txt 文件中再添加一行 hello world ，此时执行 git diff 命令，结果如下：
h、压缩提交历史
git rebase -i命令可以实现提交历史的压缩。比如我们在开发某一个功能时，提交了很多次，当所
有功能都写完时，想将这些提交压缩为一个，就可以使用该命令。
5，撤销代码
a、工作区的代码想撤销
git checkout xxx
可能有一天我正在写代码，写了很久发现写错了，想恢复到一开始的状态，一个笨办法就是把刚刚写的
代码一行一行的删除，不过这种方式成本太高，我们可以通过 git checkout – 命令来撤销
工作区的代码修改。
b、add 到暂存区的代码想撤销
git reset HEAD
如果想要撤销，但是代码已经提交到暂存区了，不用担心，也能撤销，分两个步骤：
将暂存区的代码撤销到工作区。将工作区的代码撤销(具体操作和’工作区的代码想撤销’一致)。
将暂存区的代码撤销，我们可以使用 git reset HEAD 命令来实现。
核心的过程就是先执行 git reset HEAD 命令，从暂存区撤销，剩下的操作参考’工作区的代码想撤销’一节。
c、提交到本地仓库的代码想撤销
git reset --hard <版本号>
同样的，提交到本地仓库的代码一样也可以撤销，我们可以利用 git reset --hard <版本号> 命令来
实现版本回退，该命令中的版本号有几种不同的写法：
可以使用 HEAD^ 来描述版本，一个 ^ 表示前一个版本，两个 ^^ 表示前两个版本，以此类推。也可以使用数字来代替 ^ ，比如说前 100 个版本可以写作 HEAD~100 。也可以直接写版本号，表示跳转到某一个版本处。我们每次提交成功后，都会生成一个哈希码 作为版本号，所以这里我们也可以直接填版本号，哈希码很长，但是我们不用全部输入，只需要 输入前面几个字符即可（一般是 6 个或者 7 个字符），就能识别出来。
三、Git 的分支
1、分支的必要性
2、查看分支
git branch
我们可以通过 git branch 命令来查看当前仓库有哪些分支，而我们处于哪一个分支中，如下：
这里显示当前仓库只有一个 master 分支，这是 git 默认创建出来的，master 前面的 * 表示我们当前 处于这一个分支中。
3、分支创建和切换
创建分支：git branch <分支名>
切换分支：git checkout <分支名>
创建并切换分支：git checkout -b <分支名>
切换回上一个分支：git checkout -
我们可以利用 git branch <分支名> 命令来创建一个分支，然后利用 git checkout <分支名> 来切
换分支，如下：
如果小伙伴觉得这样太麻烦，可以通过 git checkout -b <分支名> 来一步到位，创建并切换分支，如
下：
4、分支合并
分支合并：git merge --no-ff <分支名>
现在我切换到 fa 分支中，由于 fa 分支是从 master 分支中创建出来的，所以此时 fa 分支的内容和
master 分支的内容是一致的，然后我在 fa 分支中向 git01.txt 文件添加一行内容并提交，此时 fa 分支
中的 git01.txt 和 master 分支中 git01.txt 的内容就不相同了，具体操作如下：
上图展示了此时 master 分支和 fa 分支的不同，现在我通过 git merge --no-ff <分支名> 命令将 fa
分支合并到 master 分支上。其中 --no-ff 表示强行关闭 fast-forward 方式， fast-forward 方式表示当 条件允许时， git 直接把 HEAD 指针指向合并分支的头，完成合并，这种方式合并速度快，但是在整个过程中没有创建 commit，所以如果当我们删除掉这个分支时就再也找不回来了
想要合并分支，我们先切换到 master 分支上，然后执行 git merge --no-ff fa 命令即可完成分支合 并。
5、以图表的方式查看分支
查看分支：git log --graph
我们可以通过 git log --graph 命令来直观的查看分支的创建和合并等操作，如下图：
6、分支衍合
所谓的分支衍合其实也是分支合并的一种方式，下面我们就来看看这个分支衍合到底是什么样的。现在我的 master 分支的内容和 fa 分支的内容是保持一致的，fa 是从 master 中创建出来的，如下图：
现在我向 fa 和 master 中各自做一次提交，如下图：
此时我们执行如下两条命令将两个分支合并：
四、远程仓库
这里只讲 github 的使用，如果是 gitee，使用方式跟 github 基本一样的。
1、查看本地是否已有 SSHKEY
SSH KEY 的配置不是必须的，不配置的话我们就只能使用 HTTPS 协议，这样每次提交时要输入用户名密码，略麻烦，所以还是配置一下。配置 SSH KEY 的原理很简单，采用非对称加密方式生成公钥和私钥，公钥告诉 GitHub ，私钥留在自己电脑上(私钥不可泄露)，当我们向 GitHub 上提交数据时，GitHub 会用我们留给它的公钥加密一段消息返回给我们的电脑，如果我们能够用私钥解密成功，说明是合法的用户，这样就避免我们输入用户名密码了。大致的原理就是这样，现在很多免登录的系统都采用了这种方式，比如 Hadoop 免登录配置也是这样。那我们就来看看这个 SSH KEY 要怎么生成。
2、生成 SSH 指纹：
生成 SSH 指纹的命令很简单，如下：
ssh-keygen -t rsa -b 4096 -C "你的邮箱地址"
3、添加 ssh 到 ssh-agent 中
执行如下命令即可：
eval "$(ssh-agent -s)"
OK，做好这一切之后，我们当前用户目录下已经有了一个名为 .ssh 的隐藏文件夹了，打开这个目录，会发现有一个名为 id_rsa.pub 的文件，这就是我们一会要使用的公钥文件。
4、将公钥告诉 GitHub
点击头像，下拉菜单中选择：
接着最左边的菜单栏选择：
点击这个：
然后：
完了之后点击最下面的 Add SSH key 按钮即可，如此之后，我们的 SSH KEY 就配置成功了。
5、创建远程仓库
接下来在 GitHub 上创建一个仓库，登录成功之后，直接点击右上角绿色的 New repository 按钮，如下：
6、关联远程仓库
创建仓库之后，可以看到仓库的地址：
首先，点击这里，查看有几个仓库，然后随便点击一个仓库：
一般都用 SSH ，当然其他两个有需要可以自行选择。
然后我需要将我们之前的本地仓库和这个远程仓库进行关联，使用 git remote add 命令，如下：
git remote add origin <仓库地址>
在这条命令中，git 会自动将远程仓库的名字设置为 origin ，方便我们的后续操作
7、推送到远程仓库
a、推送 master 分支
假设我想将本地 master 分支上的内容推送到远程 master 分支上，方式如下：
git push -u origin master
-u 参数可以在推送的同时，将 origin 仓库的 master 分支设置为本地仓库当前分支的 upstream（上游）。添加了这个参数，将来运行 git pull 命令从远程仓库获取内容时，本地仓库的这个分支就可以直接从 origin 的 master 分支获取内容，省去了另外添加参数的麻烦。这个参数也只用在第一次 push 时加上，以后直接运行 git push 命令即可。
b、推送到其他分支
如果想推送到其他分支，还是这条命令，修改一下分支的名字即可，执行如下命令：
先切换 fa 分支：git checkout <分支名>
然后推送 fa 分支：git push -u origin <分支名>
先切换到 fa 分支，然后执行 git push 命令，参数含义和之前的一样，这里我们创建的远程仓库的分支名也为 fa（当然我们可以取任何名字，但是为了不混淆，最好取一致的名字）。这两条命令执行成功之后，此时在网页中我们就可以看到已经有多个分支了，如下：
8、从远程仓库获取
a、第一次获取
刚刚是我们向远程仓库提交数据，有提交当然就有获取，我们可以通过 git clone 命令克隆一个远程仓库到本地，方式也简单，创建一个空文件夹，然后执行如下命令：
git clone <仓库地址>
表示克隆文件到本地仓库。此时克隆的远程仓库的 master 分支到本地仓库，我们可以通过 gitbranch -a 来查看本地仓库和远程仓库的信息，-a 参数可以同时显示本地仓库和远程仓库的信息，如下：
我们看到远程仓库中已经有了 fa 分支了，如果我们想把 fa 分支也克隆下来，执行如下命令：
git checkout -b fa origin/fa
表示根据远程仓库的 fa 分支创建一个本地仓库的 fa 分支，创建完成之后进行切换，也可以通过如下命令只创建不切换：
git branch fa origin/fa
9、从远程仓库更新
此时我们回到第一次最早的那个 test 本地仓库中，那个 test 仓库的 fa 分支现在和远程仓库不一致了，我们可以通过 git pull 命令来更新，如下：
a、分支问题
小伙伴遇到的问题是这样的：
现在有一个 master 分支，master 分支中有一个文件叫 01.txt ，该文件中只有一行数据，然后对01.txt 执行 add 和 commit ，然后再从 master 分支中创建出一个新的分支 fa ，切换到 fa 分支上，然后向 01.txt 中再添加一行数据，添加成功之后，不做任何事情，再切换回 master 分支，此时用 cat 命令查看 01.txt 文件，发现竟然有两行数据，按理说 master 中的 01.txt 只有一行数据，而 fa 中的01.txt 有两行数据。
要搞清楚这个问题，得先明白下面这个问题：
可能眼尖的小伙伴已经发现端倪了，我们上面这个操作少了两个步骤，那就是 add/commit ，fa 分支中的数据修改之后直接切换回了 master ，而没有 add/commit 。正常情况下（修改数据后add/commit），如果 master 和 fa 分支中的数据不一致，我们执行了 git checkout - 进行分支的切换，这个时候工作区中的文件内容也是会跟着变化的（大家可以通过 cat 命令或者直接在记事本中打开工作区的文件来查看这种变化），但是如果我在 fa 分支中修改了文件却没有 add/commit 就切换回master ，此时如果工作区的文件变化了，可能会导致我在 fa 分支中的修改丢失，因此，这个时候工作区的文件就没有变化，即工作区的文件内容还是 fa 分支中修改的内容。
b、分支问题解决方案一
第一种解决方案就是在某一个分支修改文件之后，先 add 并且 commit 之后再去切换分支，这个操作就比较简单了，我这里就不再演示了。
c、分支问题解决方案二——储藏
储藏分支：git stash
恢复刚刚储藏的数据：git stash apply
查看储藏：git stash list
恢复到之前的某一次储藏：git stash apply stash@{储藏的名字}
d、其他关于储藏的命令
还有一些其他的关于储藏的命令：
恢复储藏并出栈：git stash pop
删除某一个储藏：git stash drop stash@{储藏的名字}
10、轻量级标签
轻量级标签就像是个不会变化的分支，实际上它就是个指向特定提交对象的引用。
首先我们可以通过如下命令来查看当前仓库中的所有标签：
查看当前仓库中的所有标签：git tag
打标签的方式很简单，直接通过 git tag 来完成即可。
打标签：git tag <tagname>
我们可以利用 git show 来查看标签对应的版本信息，如下：
查看标签对应的版本信息：git show <tagname>
删除标签：git tag -d <tagname>
给历史上的某次 commit 打一个标签：git tag <tagname> <哈希码>
11、含附注的标签
而含附注标签，实际上是存储在仓库中的一个独立对象，它有自身的校验和信息，包含着标签的名字，电子邮件地址和日期，以及标签说明，标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证。
打一个含附注的标签：git tag -a <tagname> -m <msg>，比如：
如果不加最后的版本号参数，表示给最新的一次 commit 打标签。
12、签署标签
说到签署标签我们得先介绍一下 GPG ：
使用签署标签我们先要生成 GPG Key，生成命令：gpg --gen-key
能默认的就直接按回车默认，不能默认的就根据提示输入相应的值，这里的都很简单，不再赘述。完了之后，就可以通过如下命令来打标签了：
13、标签推送到远程仓库
git push 命令并不会把tag提交到远程仓库中去，需要我们手动提交，如下：
标签推送到远程仓库：git push origin <tagname>
提交所有的 tag 到远程仓库：git push origin --tags
五、IDEA 中使用Git
事先声明，博主的 IDEA 是的 1.3 版本，所以有些便捷的功能可能有些地方没有。
要使用 IDEA 中的 Git 当然首先是电脑已经装了 git。
1、设置 IDEA 中的 Git 和 Github
从 .08.13 号开始，IDEA 上配置 GitHub 有一个小小的变化，即不能使用用户名密码的方式登录了，如果你尝试用用户名/密码的方式登录 GitHub 提交代码，会收到如下提示：
所以要先去获取账户的 token
a、获取 github 账户的 token
在进行下面的操作前， 首先要获取 github 账户的 token：
首先点击 github 的右上角，下拉菜单点击 setting，然后看到右边的菜单：
接着，填一下基本信息，选一下权限即可（权限需要选择 repo 和 gist，其他根据自己的需求选择）：
b、设置 git 和 github
生成一个令牌，拷贝到 IDEA 中即可：
2、克隆项目
第一步，当然是克隆项目。找个空白文件夹，然后客隆项目，也就是从远程仓库拉项目下来：
然后点击客隆即可完成客隆项目。
3、IDEA 中的 git 使用
客隆项目后，会见到目录里面有这么个文件：
当有这个 .git 的文件夹的时候，IDEA 中右上角会显示 git 的使用图标（因为有这个文件夹，所以知道这个项目是被 git 管理的）：
可以发现这里的图标展示的功能不完全。
还有其他地方可以操作 git ：
右键点击项目，可以看到如下菜单：
也可以点击 IDEA 上面的 VCS：
当然最常用的还是右下角：
可以看到右下角可以显示当前分支：
右下角可以进行 git 的相关操作。因为博主的 IDEA 版本问题，所以有些功能这里没有，比如从当前分支拉一个新分支，还有当前分支只能操作 Rename，但是没有 push 这些功能，不过都没关系，这些功能其他地方操作都是可以的。
4、增加右上角 IDEA 快捷操作图标
前面可以看到右上角的快捷操作图标很少：
可以去设置里面查看图标：
接下来添加图标：
往下拉，看到 git，点开：
这里就可以添加图标了。
博主放上常用的功能：
5、部分常用功能图标解释
6、配置哪些文件不上传
在实际项目中，很多配置文件是不用上传到远程仓库的。在项目目录下新建一个.gitignore，在里面配置哪些文件不用上传：
一般而言，properties 也是不需要的，这里博主没有展示。
常用配置：
HELP.mdtarget/.mvn/.gitignoremvnwmvnw.cmdREADME.md### STS ###.apt_generated.classpath.factorypath.project.settings.springBeans.sts4-cache### IntelliJ IDEA ###.idea*.iws*.iml*.ipr### NetBeans ###/nbproject/private//nbbuild//dist//nbdist//.nb-gradle/build/!**/src/main/**/build/!**/src/test/**/build/### VS Code ###.vscode/
7、IDEA 中文件颜色含义
在使用了 Git 之后，很多小伙伴会发现文件的颜色都不一样了，有的害怕是不是出了什么问题，这里解释下：
可以看到上面的的文件有好几种颜色，这里解释下：
灰色：配置文件配置了这些文件不会提交到远程仓库。 白色：会提交到远程仓库，但是内容一直没有改动过。 蓝色：文件中的内容发生过变动（这里是博主猜测，因为刚在里面改动了东西）。 红色：新建的文件，或者说远程仓库中没有这个文件。 绿色：已经把文件 add 到暂存区，但是还没有 commit。
暂时就发现这么多，以后有其他的再继续补充。
8、在 IDEA 中操作 git
a、add 和 commit
当改动了代码时，就可以使用 add，如果有时候改动了代码但是图标没亮，要先点击左边项目栏的项目，选中项目，一般这时 add 图标就亮了。
add 完后就可以 commit：
b、版本控制和回退
点击 IDEA 最下方的如图所示按钮：
本地回退：
c、合并分支
首先要注意的是，如果要把 f1 分支合并到 main 分支，那么首先要切换到 main 分支，再操作合并！
右下角可以切换分支。然后点击合并：
到这里就介绍的基本完毕了。其他的一些操作自己去摸索吧。
六、Git 工作流
先来看 Git Flow。
1、Git Flow
Git Flow 是最早诞生也是最早被广泛使用的工作流程。
a、master 分支 和 develop 分支
在 Git Flow 中，有两个长期存在且不会被删除的分支：master 和 develop。
在这两个分支中，master 主要用于对外发布稳定的新版本，该分支时常保持着软件可以正常运行的状态，由于要维护这一状态，所以不允许开发者直接对 master 分支的代码进行修改和提交，其他分支的开发工作进展到可以发布的程度后，将会与 master 分支进行合并，并且这一合并只在发版时进行，发布时将会附加版本编号的 Git 标签。
develop 则用来存放我们最新开发的代码，这个分支是我们开发过程中代码中心分支，这个分支也不允许开发者直接进行修改和提交。程序员要以 develop 分支为起点新建 feature 分支，在 feature 分支中进行新功能的开发或者代码的修正，也就是说 develop 分支维系着开发过程中的最新代码，以便程序员创建 feature 分支进行自己的工作。
注意 develop 合并的时候，不要使用 fast-farward merge，建议加上 --no-ff 参数，这样在 master 上
就会有合并记录，关于这两个的区别，大家可以参数松哥之前的 Git 教程，这里不再赘述。
b、feature branches —— feature-xxx 特性分支（功能分支）
除了这两个永久分支，还有三个临时分支：feature branches、hotfixes 以及 release branches。我们
分别来看：
feature branches 这个是特性分支，也叫功能分支，当你需要开发一个新的功能的时候，可以新建一个feature-xxx的分支，在里边开发新功能，这也是我们日常工作的大本营，开发完成后，将之并入 develop 分支中，如下图：
c、hotfixes branches —— fixbug-xxx（修复 bug 的分支）
这个分支看名字就是用来修复 BUG 的，当我们的项目上线后，发现有 BUG 需要修复，那么就从Master 上拉一个名为fixbug-xxx的分支，然后进行 BUG 修复，修复完成后，再将代码合并到 Master和 Develop 两个分支中，然后删除 hotfix 分支，如下图：
d、release branches —— release-xxx（发版时拉的分支）
这个是发版的时候拉的分支，当我们所有的功能做完之后，准备要将代码合并到 master 的时候，从develop 上拉一个release-xxx分支出来，这个分支一般处理发版前的一些提交以及客户体验之后小BUG 的修复（BUG 修复后也可以将之合并进 develop），不要在这个里边去开发功能，在预发布结束后，将该分支合并进 develop 以及 master，然后删除 release，如下图：
大概就是这个意思。
e、总结
工作中用的其实就是类似于 Git Flow 的工作流，为什么说是类似呢？我们项目中主要是保证了master、develop 以及 release 三个分支，在此基础之上，其他随意。
2、Github Flow
GitHub Flow 相比于 Git Flow 就要容易很多了，GitHub Flow 也是 GitHub 上使用的工作流程，如果你想参与 GitHub 上的某一个开源项目，那么不妨看看 GitHub Flow。
官方给的 GitHub Flow 流程如下：
它的流程是这样的：
需要开发新功能或者修复 BUG 的时候，从 master 上拉一个新的分支下来。新的分支开发完成后，或者说当你遇到困难开发不下去的时候，都可以发起一个 pr（Pull Request）。
GitHub 工作流虽然用着很简单，但是他的问题也很明显，就是没有对常见的工作场景中的问题提出解决办法。
3、GitLab Flow
GitLab Flow 结合了 Git Flow 与 GitHub Flow 的优点，它不像 Git Flow 有那么多容易把新手绕晕的分支，同时它又可以适应不同的开发环境。
GitLab Flow 的最大原则叫做 upstream first，中文译作“上游优先”：即只存在一个主分支 master，它是所有其他分支的 upstream，只有上游分支采纳的代码变化，才能应用到其他分支。
对于“持续发布”的项目，我们可以在 master 分支以外，再建立不同的环境分支。例如开发的分支是master，预发布的分支是 pre-production，生产环境的分支是 production。在这里开发分支是预发分支的 upstream，预发分支又是生产分支的 upstream。
代码的变化，必须由上游 向 下游 发展。比如，生产环境出现了 bug，这时就要新建一个功能分支，先把它合并到 master，确认没有问题，再 cherry-pick 到 pre-production，这一步也没有问题，才进入 production，如下图
只有紧急情况，才允许跳过上游，直接合并到下游分支。
有稳定的版本需要发布时，我们就从 master 上拉一个新的分支出来，作为发版时候的分支，这些分支
上不要开发新功能，只有修补 BUG 的时候对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。
以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号即可。
Git的使用——Git 常用命令总结 Git的使用 Git 的分支 远程仓库的使用 IDEA 中使用Git Git 工作流（Git Flow Github Flow GitLab Flow）
