推荐文章： Git 常用命令手册 直接使用git pull拉取代码，被同事狠狠地diss了！ 这篇文章把git merge 、git fetch、git pull、git rebase说的清清楚楚。
核心概念
HEAD： 当前 commit 在哪里，HEAD 就在哪里，这是一个永远自动指向当前 commit 的引用，所以你永远可以用 HEAD 来操作当前 commit。 head 相当于一个指针，commit在哪里就指向哪里。HEAD 是 Git 中一个独特的引用，它是唯一的。
branch: 是分支。HEAD 除了可以指向 commit，还可以指向一个 branch，当它指向某个 branch 的时候，会通过这个 branch 来间接地指向某个 commit；另外，当 HEAD 在提交时，自动向前移动的时候，它会像一个拖钩一样带着它所指向的 branch 一起移动。
branch 只是一个指向 commit 的引用，但它有一个更通俗的理解：你还可以把一个 branch 理解为从初始 commit 到 branch 所指向的 commit 之间的所有 commits 的一个「串」
所有 branch 之间是平等的，master 除了上面我说的那几点之外，并不比其他 branch 高级。这个认知的理解对于 branch 的正确使用非常重要。
branch 包含了从初始 commit 到它的所有路径，而不是一条路径。并且，这些路径之间也是彼此平等的。
push 上传当前分支，并不会上传 HEAD；远程仓库的 HEAD 是永远指向默认分支（即 master）的。
git commit
git log 打印日志
命令汇总
git init： 一个项目要和git相连接，就要初始化一下生成.git,才能进行下面的操作。
.gitignore不要提交到git上的文件，一般是node_modules，dist等文件，和npmignore文件很像。一般npm里面上传的是打包以后的文件，源码都会放在github上，这样npm install下载的包就会很小。可以减小我们项目的体积。
git add：将文件提交到本地缓存区 git add . 和git add -A
git status 查看提交的文件。
git commit -m "feat: XXXXX"提交本地
git push 上传github库，如果当前分支是一个本地创建的分支，需要指定远程仓库名和分支名，用 git push origin branch_name 的格式，而不能只用 git push；或者可以通过 git config 修改 push.default 来改变 push 时的行为逻辑。
git pull 从线上往自己电脑里面拉代码
git clone http://XXXX clone一个项目。 
git reset origin 分支 --hard 重置。
git branch feature1创建分支：
git checkout feature1切换分支：
git branch -d feature1 删除本地分支
git branch -D feature1 删除远程分支
git merge ： 从目标 commit 和当前 commit （即 HEAD 所指向的 commit）分叉的位置起，把目标 commit 的路径上的所有 commit 的内容一并应用到当前 commit，然后自动生成一个新的 commit。
git merge branch1 ：在master上把branch合并到master上
如何合并的时候发现同一个文件，同一个地方，两个分支都改了，就会出现冲突。
直白点说就是，你的两个分支改了相同的内容，Git 不知道应该以哪个为准。如果在 merge 的时候发生了这种情况，Git 就会把问题交给你来决定。具体地，它会告诉你 merge 失败，以及失败的原因：
处理办法：
- 解决掉冲突
- 手动
commit一下
放弃解决冲突： git merge --abort
这种情况，只能在master上重新创建新的分支，然后把feature1上面的代码merge过去。
git merge branch1 换成 git rebase
rebase 的意思是，给你的 commit 序列重新设置基础点（也就是父 commit）。展开来说就是，把你指定的 commit 以及它所在的 commit 串，以指定的目标 commit 为基础，依次重新提交一次
删除要素
-
HEAD指向的branch不能删除。如果要删除HEAD指向的branch，需要先用checkout把HEAD指向其他地方。 -
由于 Git 中的
branch只是一个引用，所以删除branch的操作也只会删掉这个引用，并不会删除任何的commit。（不过如果一个commit不在任何一个branch的「路径」上，或者换句话说，如果没有任何一个branch可以回溯到这条commit（也许可以称为野生commit？），那么在一定时间后，它会被 Git 的回收机制删除掉。）
出于安全考虑，没有被合并到 master 过的 branch 在删除时会失败（因为怕你误删掉「未完成」的 branch 啊）：
场景一：
在branch1的分支上合并master
git checkout branch1
git rebase master
可以看出，通过 rebase，5 和 6 两条 commits 把基础点从 2 换成了 4 。通过这样的方式，就让本来分叉了的提交历史重新回到了一条线。这种「重新设置基础点」的操作，就是 rebase 的含义。
git rebase 目标基础点
场景二：
git commit以后发现有个地方错了，咋办？你当然可以修改后再提交的，不过这么多补丁，确定很好？
git add 笑声.txt
git commit --amend
场景三，如果push上去，但是没有你发现有错误，咋办？
git push origin branch1 -f
git revert HEAD^
场景四 快快快，立即给我打个包，现在马上，拜托拜托！
当前分支branch1： git stash，把你做的事情藏起来
然后你就可以切换 git checkout branch2 上忙了，等忙完以后，再切回 git checkout branch1
执行git stash pop，就会回到你火急火燎的前一刻。
git stash pop 拉回add的所有文件
git stash -u 把没有add的也能拉回来。
场景五 删完分支以后才发现它还有用，咋办？
git reflog 拿到删除之前这一次的commit号，然后用git checkout 切近分支号，然后创建被删除的分支
git checkout c08de9a
git checkout -b branch1
