导言

git之所以复杂，是维护了本地分支，本地主干。远程分支，远程主干，以及工作区和暂存区之间的关系。

• 工作区：在idea中实际上是创建文件，但未add，此时文件是红色的。
• 暂存区：在idea中文件进行add，但是没有commit，此时文件是绿色的。
• 分支/主干：在idea中进行commit，此时文件是白色的。

在本地中，因为是公用了一套代码，两个分支，所以工作区和暂存区的内容在各个分支中是共享的。

但若是代码提交到分支上，那么主干上看不到提交到分支的代码。实际上主干和分支是两个指针。若是分支代码版本是新的，那么如下图所示：

image

我们若checkout（切换分支）到master，是看不到dev最新commit的代码的。

而实际上我们合并分支时，只是将master指针指向dev节点上，完成了快速合并。（故在dev分支上进行merge(合并)）。

注：合并分支时，项目中 不能存在 只add（即idea绿色文件）的文件。

理论

每次提交Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

上面的是什么意思呢？
每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长

image.png

image

image

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

image

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

image

真是太神奇了，你看得出来有些提交是通过分支完成的吗？

1. 文件初创

1.1. 新建文件

image.png

1.2、查询文件状态

命令：git status

image.png

1.3. 将文件保存到暂存区

命令：git add 文件名，再次使用git status查询状态。

image.png

1.4.将文件保存到当前分支（本地仓库）

命令：git commit -m '注释'

image.png

1.5. 查询文件修改的内容

命令：git diff 文件名

image.png

使用git status查询状态，使用git diff 文件名 查询差异。

git提交文件只要两步：

1. 使用 git add 把文件添加进去，实际上就是把文件（工作区）添加到暂存区。
2. 使用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支上。

git的工作流程.png

2. 文件回退

2.1. 查询分支日志

命令：git log 可以查询当前分支的提交日志。可以使用q退出。

image.png

2.2. 分支回退版本

命令：git reset --hard HEAD^ 那么如果要回退到上上个版本只需把HEAD^ 改成 HEAD^^。是将当前分支上的文件回退一个版本。
回退git reset --hard HEAD是回退暂存区的文件。

image.png

2.3. 获取版本号

命令：git reflog若是我们将客户窗口关闭（git log命令失效），或者回退到某个版本。那么需要该命令获取版本号。

image.png

2.4. 分支回退指定版本

命令：git reset --hard 版本号（注意无空格）

image.png

2.5. 文件撤销

命令：git checkout -- 文件名【注意有空格，注意 -- 】

需要注意的是：

1. 未add命令，可以还原；
2. 已经执行git add命令，无论是否被commit均无法还原；

image.png

总结：文件恢复的办法：
第一：如果我知道要删掉那些内容的话，直接手动更改去掉那些需要的文件，然后add添加到暂存区，最后commit掉。
第二：我可以按以前的方法直接恢复到上一个版本。使用 git reset --hard HEAD^；或者git reset --hard 版本号（注意无空格）。__
第三：git checkout -- 文件名，可以将工作区还原。

3. 文件删除

将文件手动删除之后，使用git status查询状态：

image.png

此时，有两种策略：（1）文件还原；（2）文件在当前分支上删除；

3.1 文件还原

命令：git checkout -- 文件名，因为只是在工作区做出的修改，所以可以撤销操作。

image.png

3.2 分支上删除

命令：先执行add命令，而后执行commit命令。

执行add命令后不能撤销删除.png

文件在分支上删除.png

4. 分支的创建和合并

4.1 分支的创建

git checkout 命令加上 –b参数，表示创建并切换，相当于如下2条命令
　　git branch dev （创建分支）
　　git checkout dev（切换分支）
git branch（查看所有分支）：

创建并切换分支.png

4.2 多分支之间操作

在dev分支上修改TestSort.java文件，使用git diff 文件名命令查询差异。

修改TestSort.java文件.png

add+commit命令将工作区文件合并到dev分支上。

将修改文件合并到dev分支.png

切换分支：命令：git checkout 分支名。并未在当前分支上查询到修改的信息。

分支切换后内容消失.png

4.3 分支合并

命令：git merge -d 分支A。将分支A合并到当前分支。

Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把fenzhi1指向dev的当前提交，所以合并速度非常快。可以查看文件中，已经含有了dev分支的修改内容。

多分支合并.png

4.4 分支删除

命令：git branch -d 分支A。将分支A删除。

分支删除.png

查看分支：git branch
创建分支：git branch name
切换分支：git checkout name
创建+切换分支：git checkout –b name
合并某分支到当前分支：git merge name
删除分支：git branch –d name

5. 分支冲突

5.1 冲突的产生

在dev分支上，对TestSort.java文件进行修改。然后提交到当前分支。

dev分支上合并操作.png

通过命令：git checkout 分支名 切换分支后，查看分支内容。

fenzhi1上并无修改内容.png

在master分支上修改同一个文件，然后提交到分支上。

在fenzhi1分支修改同一个文件.png

以上是合并冲突的准备工作
此时，在将dev分支上代码合并到主干（master）上时，出现版本冲突。

合并冲突.png

于是我们开始检查冲突的代码：Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，其中<<<HEAD是指主分支修改的内容，>>>>>dev是指dev上修改的内容。

检查冲突代码.png

我们修改冲突代码后，将其重新放入暂存区，然后提交到master主干上。

解决冲突.png

通常合并分支时，git一般使用”Fast forward”模式，在这种模式下，删除分支后，会丢掉分支信息，现在我们来使用带参数 –no-ff来禁用”Fast forward”模式。首先我们来做demo演示下：

1. 创建一个dev分支。
2. 修改readme.txt内容。
3. 添加到暂存区。
4. 切换回主分支(master)。
5. 合并dev分支，使用命令 git merge –no-ff -m “注释” dev
6. 查看历史记录

切换分支

合并并删除分支.png

查询分支日志.png

分支策略：首先master主分支应该是非常稳定的，也就是用来发布新版本，一般情况下不允许在上面干活，干活一般情况下在新建的dev分支上干活，干完后，比如上要发布，或者说dev分支代码稳定后可以合并到主分支master上来。

6. （精华）多人协作

当你从远程库克隆时候，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且远程库的默认名称是origin。

6.1 查询远程仓库

要查看远程库的信息 使用 git remote
要查看远程库的详细信息 使用 git remote –v

查看远程库的信息.png

6.2 数据推送

命令：git push 远程服务器名 远程分支名，将信息push到远程仓库。

image.png

那么一般情况下，那些分支要推送呢？
master分支是主分支，因此要时刻与远程同步。
一些修复bug分支不需要推送到远程去，可以先合并到主分支上，然后把主分支master推送到远程去。

6.3 抓取分支：

命令：git push origin dev小胖将信息push到远程dev分支上

用户A将信息push到远程dev分支上.png

小伙伴要在dev分支上做开发，就必须把远程的origin的dev分支到本地来，于是可以使用命令创建本地dev分支：git checkout –b dev origin/dev
现在小伙伴们就可以在dev分支上做开发了，开发完成后把dev分支推送到远程库。

将远程分支拉到本地.png

小胖将TestSort.java修改的内容推送到远程。

image.png

小悠也想对TestSort.java这个文件信息修改。于是：

image.png

由上面可知：推送失败，因为我的小伙伴最新提交的和我试图推送的有冲突，解决的办法也很简单，上面已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后在本地合并，（手动）解决冲突，再推送。

因此：多人协作工作模式一般是这样的：
首先，可以试图用git push origin branch-name推送自己的修改;
如果推送失败，则因为远程分支比你的本地更新早，需要先用git pull试图合并。
如果合并有冲突，则需要解决冲突，并在本地提交。再用git push origin branch-name推送。

7. 应用实战（idea版本）

7.1 idea文件和git版本的关系

idea文件的颜色和版本的关系

7.2 场景1

git使用场景：

开发过程中，忘记将主干上的代码pull（远程分支下拉命令）或者merge（本地主干下拉命令）。且开发到一半时（已存在大量“蓝色/绿色”文件），此时再想pull或者merge时候。出现

下拉代码的异常

解决方案1：

如果你想保留刚才本地修改的代码，并把git服务器上的代码pull到本地（本地刚才修改的代码将会被暂时封存起来）
git stash
git pull origin master
git stash pop

等价于git stash，将修改代码保存起来

这个是将本地主干代码拉取到本地分支（相当与远程服务器拉取的git pull origin master命令）

拉取完毕，恢复存储的改变，可能后续存在解决冲突的问题

解决方案2：

如果你想完全地覆盖本地的代码，只保留服务器端代码，则直接回退到上一个版本，再进行pull：
git reset --hard
git pull origin master

文章参考：https://www.cnblogs.com/replaceroot/p/9825760.html
　　　　　http://www.admin10000.com/document/5374.html