git相关

Delta compression using up to 4 threads. Total 12 (delta 5), reused 0 (delta 0) The remote end hung 

没有权限

soft 把这个版本之前改为待提交状态 变成蓝色 就这

mixed  把这个版本之前改为删除状态 变成 暗红色  就就这

hard 舍弃之前所有更改 但是没有前面两个提交功能 感觉和checkVerion 差不多

keep 和hard 差不多 只不过如果本地有改变未提交的就回弹出框 问你是hard reset还是smart reset

smart retset其实就是解决差异

revert commit 就是从当前版本回退到上一次版本 当如果之后如果还有修改i的 会有冲突

可以说解决冲突 accept Theirs 就是上一个版本

如果是最新一个回退提交 那么就是回退上一个版本 重新提交

git revet commit 会把 该次提交之后的所有对涉及到本次 回退文件的所有变更 全回退了

git merger  master  出来一个分支  master 在改改 分支 也在改改 最后想把 分支合并到master

如果说是 在master 分支拉出来的时间节点 以后 双方 都改过的代码那么会冲突 显示出来让合并

如果 说只有master后续 改过 分支没改过 那也没问题  master保持原样

如果 master 没改过 分支改 那么 会自动合并不会提示 

最后关键的是一个问题  加入说 分支后来又更新 master 这个后续 代码 最后要看这不对 给删除了

那么 在合并 就会以分支为准 覆盖掉master 代码  切记小心 不要在分支 去更新主干代码 

git rebase 
假设有一个项目 master feature

主干提交记录为 123  feature 也是从这里拉出来的

然后master提交了 4,5 feature提交了6,7
然后在 feature rebase feature onto master

那么 就会以master提交记录提到最前  不管各自提交时间如何  现在的提交记录 12345 67
feature在拉出master分支改的记录始终在最后面 而且 67提交版本 会挨个跟 5比较冲突  5始终的合并 虽然之前合并过
这个还是不要用经过测试  会打乱你的提交代码

git 分支合并
从同一个时间线拉出来两个分支 时间线A

如果是同一文件代码都改过
左边是当前分支改过的代码 中间是 时间线A初始代码 右边是被合并代码分支 （如果 A 合并过B（时间线D） 那么B在合并A的时候 左边展示的是 时间线D之后B改过的代码 中间 是时间线D B的代码 右边是A时间D前后 B没有合并过的代码）

如果说你不想合并想回退 那么 那么看当前分支reset branch to here 看你合并之前的最新提交记录 就行 这个会把被合并代码全部干掉
但是你如果选择的历史提交记录是被合并分支的记录 那么反而会把当前分支的提价记录都干掉

git push  origin dev -f