git的常规使用（包括冲突的产生和解决。干货）

1.git的用户名

git config --global user.email [xx的mail@email.com]
git config --global user.name[xx的mail@email.com]

1.1git的初始化本地仓库

git  init

1.2需要追踪（记录）那些文件 （.是全部）

git  add .（点是一个可变参数接受通配符）
刚新建的项目就直接push就好了
没有追踪的文件都会被打上untracked”（未跟踪）标记
追踪完之后会出现  staged”（已暂存）

1.3查看本地仓库的提交日志

git log
git log -p 查看详细信息
git log --stat  大致看一下改动内容，但并不想深入每一行的细节
可以查看提交的信息，作者，日期，历史id号

1.4是用来查看工作目录当前状态的指令

git status
你在 master branch
当前 branch 没有落后于 origin/master
你有 untracked files （未追踪的文件），文件名是 shopping list.txt。
你可以使用 git add 来开始追踪文件。

1.5查看任意的commit

git show 5e68b0d8  （branch 或 HEAD 标记）或它的 SHA-1 码

1.6比对暂存区和上一条提交

使用 git diff --staged 可以显示暂存区和上一条提交之间的不同。
换句话说，这条指令可以让你看到
「如果你立即输入 git commit，你将会提交什么」：

2.获取新代码（每次在新的分支开发前最好先拉取最新的代码，可以减少部分冲突）

git pull '分支名（可选参数）'

3.克隆代码（也叫拉代码）

git  clone '代码地址'

4.1提交到暂存中

git  commit -m  '提示信息'
vscode中用鼠标操作的区域结果是一样的

4.2.推送到分支

git  push  origin '分支名'

4.分支的切换和创建

git  checkout '分支名'  
git checkout -b  '分支名' (创建分支并切换到该分支)
注：切换分支之前要先暂存或者push代码，不然切换不了分支

5.分支的合并

   先切checkout要合并到的分支下
   例如：我要将dev1分支的代码合并到dev中。就要切换到dev中在执行以下命令
git  merge '分支名'

因为git的作用是代码管理。所以在团队开发中会遇到多人操作同一个文件的情况，这样就会产生冲突。git就不知道你是想保留谁的代码。

就像我们在微信群中发一个文件表给群里的人编辑。每个人拿到的都是初始的文件，而每个人进入到文件只编辑自己的信息最后发回群里，这样每个人发的文件都只是自己的信息。而不是一个所有人信息都有的文件。所以发文件的人还要下载每个人的文件来一个个拿出来整和到一个文件中

1. 例如我在master分支中创建了一个index.html
   
   然后切换到了devloap分支中也创建了一个一模一样的文件
   
   然后将切换到master分支把devloap合并。这就产生了冲突 (conflict)
   
   点进去就是
   
   
   这些冲突基本都是手动解决的
   
   保留原来|接收更改|保留两个|删除其中一个
   经验：不要将过大的文件放进代码仓库，代码仓库就只是存代码和小图片的。过大的资源还是存在服务器中。不然将导致拉取代码会报错的问题

报错：

fatal: refusing to merge unrelated histories
他人的解决方案

实际项目中也是一样的。操作多了基本都是这样解决。不过要找的出自己要修改的代码。判断哪些是要保留的或者是更改的。这些都是自己积累的经验。出bug和冲突心态一定要好。。。。。。。。。还会更新

进阶

1.HEAD、master 与 branch

HEAD：当前 commit 的引用.就是当前提交信息的id很长的一串字符
每次进行一次commit HEAD就会指向最新的commit
所以通过git log 看到的第一条commit都是有HEAD 往下的几条都是没有的
切换分支的时候HEAD也会跟着移动

2.删除分支

1. HEAD 指向的 branch 不能删除。如果要删除 HEAD 指向的 branch，需要先用 checkout 把 HEAD 指向其他地方。
2. 由于 Git 中的 branch 只是一个引用，所以删除 branch 的操作也只会删掉这个引用，并不会删除任何的 commit。（不过如果一个 commit 不在任何一个 branch 的「路径」上，或者换句话说，如果没有任何一个 branch 可以回溯到这条 commit（也许可以称为野生 commit？），那么在一定时间后，它会被 Git 的回收机制删除掉。）

3. push

push 的时候只会上传当前的 branch 的指向，并不会把本地的 HEAD 的指向也一起上传到远程仓库。事实上，远程仓库的 HEAD 是永远指向它的默认分支（即 master，如果不修改它的名称的话），并会随着默认分支的移动而移动的。
总结：

1. push 是把当前的分支上传到远程仓库，并把这个 branch 的路径上的所有 commits 也一并上传。
2. push 的时候，如果当前分支是一个本地创建的分支，需要指定远程仓库名和分支名，用 git push origin branch_name 的格式，而不能只用 git push；或者可以通过 git config 修改 push.default 来改变 push 时的行为逻辑。
3. push 的时候之后上传当前分支，并不会上传 HEAD；远程仓库的 HEAD 是永远指向默认分支（即 master）的。

3. merge

merge做的事：
从目标 commit 和当前 commit （即 HEAD 所指向的 commit）分叉的位置起，把目标 commit 的路径上的所有 commit 的内容一并应用到当前 commit，然后自动生成一个新的 commit。


1.这是最容易出现冲突的一个地方

情景一：
merge 在做合并的时候，是有一定的自动合并能力的：如果一个分支改了 A 文件，另一个分支改了 B 文件，那么合并后就是既改 A 也改 B，这个动作会自动完成；如果两个分支都改了同一个文件，但一个改的是第 1 行，另一个改的是第 2 行，那么合并后就是第 1 行和第 2 行都改，也是自动完成。

情景二：
如果两个分支修改了同一部分内容，merge 的自动算法就搞不定了。这种情况 Git 称之为：冲突（Conflict）。
直白点说就是，你的两个分支改了相同的内容，Git 不知道应该以哪个为准。如果在 merge 的时候发生了这种情况，Git 就会把问题交给你来决定。具体地，它会告诉你 merge 失败，以及失败的原因
解决1：打开冲突的文件，然后手动处理冲突
解决2：如果你最终决定放弃这次 merge，也需要执行一次 merge --abort 来手动取消它：

特殊情况1
如果 merge 时的目标 commit 和 HEAD 处的 commit 并不存在分叉，而是 HEAD 领先于目标 commit：

特殊情况2
而另一种情况：如果 HEAD 和目标 commit 依然是不存在分叉，但 HEAD 不是领先于目标 commit，而是落后于目标 commit：

执行merge的话。 Git 会直接把 HEAD（以及它所指向的 branch，如果有的话）移动到目标 commit：

merge的兄弟

git rebase master

撤销commit

git reset --hard HEAD^

不过，就像图上显示的，你被撤销的那条提交并没有消失，只是你不再用到它了。如果你在撤销它之前记下了它的 SHA-1 码，那么你还可以通过 SHA-1 来找到他它

git revert HEAD^
上面这行代码就会增加一条新的 commit，它的内容和倒数第二个 commit 是相反的，从而和倒数第二个 commit 相互抵消，达到撤销的效果。