【Git】git diff 的简单使用（比较版本区别）
<<<<<<< HEAD
本地代码
=======
拉下来的代码
>>>>>>>
1.比较修改之间的差异
git diff不加参数即默认比较工作区与暂存区
git diff --cached [
git diff HEAD [
git diff commit-id [
git diff --cached [
git diff [
例如，比较工作区和暂存区的main.cpp文件的差异。
$ git diff main.cpp
diff --git a/main.cpp b/main.cpp
index 57a5778..24604db 100644
--- a/main.cpp
+++ b/main.cpp
@@ -1,6 +1,7 @@
#include
using namespace std;
int main(){
- cout<<"Hello, World!"<
2.制作补丁
git diff还可以制作补丁文件，在其他机器上对应目录下使用 git apply patch 将补丁打上即可
git diff > patchpatch的命名是随意的，不加其他参数时作用是当我们希望将我们本仓库工作区的修改拷贝一份到其他机器上使用
git diff --cached > patch是将我们暂存区与版本库的差异做成补丁
git diff --HEAD > patch是将工作区与版本库的差异做成补丁
git diff filename > patch将单个文件做成一个单独的补丁
git apply patch 应用补丁。
应用补丁之前我们可以先检验一下补丁能否应用，git apply --check patch 如果没有任何输出，那么表示可以顺利接受这个补丁。
使用git apply --reject patch将能打的补丁先打上，有冲突的会生成.rej文件，此时可以找到这些文件进行手动打补丁。
原文链接：https://blog.csdn.net/ezhchai/article/details/79387452
假如我们修改viewMail.vue 文件（部分代码）
从
//根据ID获取详情
getById () {
let that = this;
this.viewMailModal = true;
this.loading = true;
post('/presidentmailinfoController/selectByPrimaryKey', {id: this.viewId, initiatorType: 3}).then(res => {
that.loading = false;
if (res.success) {
let mail = res.data
// mail.content = that.formatTxt(mail.content)
that.imgList = mail.fileList
that.mailInfo = mail;
}
});
},
修改为
//根据ID获取详情
getById () {
let that = this;
this.viewMailModal = true;
this.loading = true;
// post('/presidentmailinfoController/selectByPrimaryKey', {id: this.viewId}).then(res => {
post('/presidentmailinfoController/selectByPrimaryKey', {id: this.viewId, initiatorType: 3}).then(res => {
that.loading = false;
if (res.success) {
let mail = res.data
// mail.content = that.formatTxt(mail.content)
that.imgList = mail.fileList
that.mailInfo = mail;
}
});
},
就在post 位置 多加了 一行注释和 多加了一个字段 initatorType 字段 ，好吧这不重要，我只是不行写简单的例子了，直接用的项目中的代码作为例子。
。我们记住区别就行了。
修改完毕后我们打开 git 命名行。
运行命令 git status 查看我们 工作区的修改的文件
git 告诉我们 一个viewMail.vue文件修改了。但是没有告诉我们这个文件里 具体修改了哪些内容。此时git diff 就排上的用场。 他可以用于比较现在 工作区（未提交到暂存区） 与 暂存区（已经通过 git add 和 git commit 提交了）。具体的修改变化。
下面我们来运行一下 git diff 命名。查看一下变化。
具体的变化就一目了然了，git 告诉我们 删除了红色行 ，新增了 绿色 行的代码。这正是我们的修改。
其实此时运行的 git diff 相当于 git diff HEAD （HEAD 指向的是 local repository 中最新提交的版本）。
我们再来看一下运行 git diff HEAD
两次的运行结果是一样的。我们再来看一下git diff 的简单说明：
git diff：是查看 workspace（工作区） 与 index（暂存区） 的差别的。
git diff --cached：是查看 index（暂存区） 与 local repositorty（本地仓库） 的差别的。
git diff HEAD：是查看 workspace 和 local repository 的差别的。（HEAD 指向的是 local repository 中最新提交的版本）
注：git diff 后跟两个参数，如果只写一个参数，表示默认跟 workspace中的代码作比较。git diff 显示的结果为 第二个参数所指的代码在第一个参数所指代码基础上的修改。如，git diff HEAD 表示 workspace 在 最新commit的基础上所做的修改
附：git 的 四个工作区（来源：【Git】(1)---工作区、暂存区、版本库、远程仓库 - 雨点的名字 - 博客园）
由上图可以看出，通常情况下， 当我们运行的 git add . ,是将工作区（workspace）的代码提交到了暂存区（index）中，然后我们经常运行的 git commit -m “修改代码提交说明”
是将暂存区中的代码提交到了本地仓库（local Repository）中。再往后就是我们通过 git push 将本地仓库的代码提交到远程仓库了（这里不多说了，主要说比较版本区别）。
这样就可以解释与git diff 和 git diff HEAD 的运行结果一样的问题了：
虽然说 git diff 是 比较 的工作区 与 暂存区 的区别，git diff HEAD 比较的是 工作区和 本地仓库的 区别。
但是有一点是，我在修改 代码前已经 运行过来 git add . 和 git commit -m "。。。" 命令了。所以 暂存区的 内容和 本地仓库的内容是一样的。
运行完后通过 git status 查看状态。已经告诉我没有要提交 的东西了。
所以运行 git diff 和 运行 git diff HEAD 的命令 结果是一样的。
下面我们再来看一下如果已经把工作区（workspace）中的代码提交到了暂存区（index）和本地仓库（local Repository）中怎么查看与上一个版本的区别。
运行如下命令进行提交：
提交完毕后查看是否还有要提交的内容
好的，已经提示没有要提交的内容了。
下面我们再来查看一下运行 git diff 和 git diff HEAD 看是否还有效果：
可以看出这两个命令已经没有输出的东西了。
相信认真看完上面内容的你，已经知道为什么了。因为此时 工作区（workspace）和 暂存区(index)、本地仓库（local Repository）的最新版本代码 都是一样的了。所以已经比较不出东西了。
那么此时我们想看这一版本的代码和上一版本的代码区别，就得使用 git diff HEAD^ 我们知道到 HEAD 代码 本地仓库的最新版本， 那么上最新版本的上一个版本就用 HEAD^ 表示， 依次类推 那么最新版本的 上一个版本的上一个版本就是 HEAD^^
那么问题来了，我们如果我们比较的版本比较久远，就会写好多 ^^^...... 很麻烦，也容易把自己写晕。所以git 还有另一种写法 git diff HEAD~X X 代表^ 的个数。 即： git diff HEAD~1 代表最新版本的上一个版本。 git diff HEAD~2 代表最新版本的上一个版本的 上一个版本。
下面我们来运行一下（看一下当前最新版本与上一个版本的区别）
很完美的展现了我们修改的代码。
我们再用 git diff HEAD~1 来查看一下。
结果是一样的。
这就是git diff 的一些简单用法。具体用法请见官网。Git - git-diff Documentation
附：
参考文章：
git: 提交前查看修改 git diff，HEAD^, HEAD~i
git: 提交前查看修改 git diff，HEAD^, HEAD~i_all for one，one for all-CSDN博客
【Git】(1)---工作区、暂存区、版本库、远程仓库
【Git】(1)---工作区、暂存区、版本库、远程仓库 - 雨点的名字 - 博客园
git diff的最全最详细的4大主流用法：
git diff的最全最详细的4大主流用法_快乐李同学的博客-CSDN博客
冲突的解决
（如果git使用不熟练）建议在push不了时，pull之前。在本地创建一个新的分支并commit到local，以保证本地有commit记录，万一出什么问题，可以找回代码，以免代码丢失。
（更甚者，把整个文件夹备份，不然出现找不回代码那就开心了）
多人开发时Git下冲突的产生和解决
演示
项目中有一个文件test.txt，其内容为（以下是在github仓库中截得文件内容）：
1、保证项目的正确性，先pull到最新版本。
2、修改local的test.txt的文件内容，修改后的内容是：
然后local查看状态，及commit到本地仓库。
3、 (再1之后)，修改test.txt，并push到remote。
（以下是我直接在github的仓库编辑提交的。）
查看remote的commit log，可以发现有一次新的提交。
这样就造成了冲突，因为local的test.txt版本与服务器的版本不一致。
4、push本地的commit，发现无法push。
发现需要先 git pull，于是先更新。
pull后，给出了明确的错误提示”Automatic merge failed; fix conflicts and then commit the result.”。
此时查看test.txt的内容：
其中<<<<<<< HEAD 到 ======= 中间的内容是local提交的。
======= 到 >>>>>>> commit-id 是远程仓库中的内容。
（和svn类似。）
如何解决冲突？ 删除这些注释，保证test.txt的内容是最终push版本的内容。
修改冲突后的test.txt内容：
特别，在eclipse中即使是解决了冲突，文件的冲突图标还在，但并不影响commit&push。如下:
5、冲突解决后，在git status可以看到当前的文件状态：
（特别需要注意的是当前分支会处在一个MERGING状态下，以及刚才处理的冲突文件test.txt处于Unmerged paths下。）
根据提示，用git add test.txt，然后在git commit和git push。
此时去看remote中的test.txt内容和commit log：
原文：【Git】git使用 - 冲突conflict的解决演示 - 淡丶无欲 - 博客园