Git常用命令

具体方法如下

git pull origin 远程分支

//出现错误

git stash  缓存起来

git pull origin 远程分支

git stash pop //还原

git stash clear

开发人员常常遇到这种情况：花了几天时间一直在做一个新功能，已经改了差不多十几个文件，突然有一个bug需要紧急解决，然后给一个build测试组。在Git问世之前基本上靠手动备份，费时且容易出错。

git stash命令简而言之就是帮助开发人员暂时搁置当前已做的改动，倒退到改动前的状态，进行其他的必要操作（比如发布，或者解决一个bug，或者branch，等等），之后还可以重新载入之前搁置的改动，很cool吧？

首先，用git add把所有的改动加到暂存区（staging area）。

git add .

接着用git stash把这些改动搁置。

git stash

到这里，当前工作平台就回复到改动之前了。该干嘛干嘛，此处省略1万字。

需要找回之前搁置的改动继续先前的工作了？

git stash apply  --即可。

也可以用 git stash list 来查看所有的搁置版本（可能搁置了很多次，最好不要这样，容易搞混）

在出现一个搁置栈的情况下，比如如果你想找回栈中的第2个，可以用 git stash apply stash@{1}

如果想找回第1个，可以用 git stash pop

如果想删除一个stash，git stash drop <id>

删除所有stash，git stash clear

git搁置区操作：

#本地git搁置区
git stash list        --查看本地git搁置区里面的搁置记录
git stash             --将本地修改代码放入本地git搁置区，如果已经放到本地git暂存区里面的代码也会放到搁置区里，同时把已经放入本地git暂存区里面的代码清空
git stash pop         --取出最后一次放入本地git搁置区里面的代码，相当于把代码从本地git搁置区里拿出来，放到本地git未暂存区里面
git stash stash@{0}   --取出最后一次放入本地git搁置区里面的代码的另外一种写法，这种写法可以取出某一次放入本地git搁置区里面的代码
git stash apply       --等同于 git stash pop
git stash clear       --清除本地git搁置区里面的所有记录
①git stash           --①将本地修改的代码放入本地git搁置区 
②git stash clear     --②清除本地git搁置区里面的所有记录，等同于git checkout .（退回最后一个历史版本）
git stash --help

还原所有文件，将服务器上的文件还原到本地，（适用于：还没有提交到本地git暂存区和本地git仓库里）

git checkout .   --回滚所有文件，之前修改的代码都没有了，等同于放弃之前所有修改操作

回滚操作（适用于：已经提交到本地git仓库里，还没有提交到远程git仓库里）

git reflog   --查看git提交的history日志
git reset --soft  xxx   --从本地git仓库里回滚到本地git暂存区里，之前修改的代码还能保留
git reset --hard  xxx   --从本地git仓库里回滚到远程git仓库history上的某一个版本，之前本地所有更改代码都没有了，等同于放弃之前所有修改操作，等同于git checkout .(退回最后一个历史版本)

--soft表示软连接：看不到git之前提交的信息，相当于从本地git仓库里面退回到本地git暂存区中

--hard表示硬链接：能看到git之前提交的信息，相当于直接回滚到远程git的历史提交某一次记录上。

重新提交git信息

git commit --amend -m "refactor|feat|test|fix|style|docs|chore|perf|ci => 按照规范要求书写git提交信息"    --相当于上次提交git的信息被重新覆盖了

删除本地git未跟踪文件和目录(未暂存文件)，只适用于本地新增文件和目录的操作

git clean -f    --删除本地git未跟踪文件 untracked files
git clean -fd   --删除本地git未跟踪文件连 untracked 的目录也一起删掉
git clean -nf   --在用上述 git clean 前，强烈建议加上 -n 参数来先看看会删掉哪些文件，防止重要文件被误删
git clean -nfd  --在用上述 git clean 前，强烈建议加上 -n 参数来先看看会删掉哪些文件，防止重要文件被误删

删除github中某个文件夹

#删除github中某个文件夹
git rm -r --cached tb.com.sbmsm.demo/.idea
git commit -m '删除了.idea文件夹'
source tree 推送操作

Git 强制退回某一版本,Git回滚代码到某个commit

#强制退回某一版本，一旦推上去，这个版本之后的那些更改就完全没有了，一定注意。
git reset --hard HEAD^         回退到上个版本
git reset --hard HEAD~3        回退到前3次提交之前，以此类推，回退到n次提交之前
git reset --hard 版本信息SHA    回退到某一个版本
git push -f -u origin dev      强推到远程
git push origin HEAD --force   强推到远程

其他操作

#列出所有本地git分支
git branch
#列出所有远程git分支
git branch -r
#列出所有本地和远程git分支
git branch -a
#切换本地dev分支
git checkout -b dev
#切换远程dev分支
git checkout -b remotes/origin/dev
#列出所有tag
git tag

git 删除某个中间提交版本

找到要删除的那条记录下面的提交记录hash值

git rebase -i 8e4ae247bd3d64ce12780c2f4056d7edf71d4af4

之后弹出一个文件（类似：vi命令编辑文件）

将 pick 48bcfa87f 之前的 pick 改为 drop，保存文件（:wq!）。

之后用source tree重新推送另外一个分支名称到远程服务器，如果还用原来的分支名称是推不上去的。

在服务器上把原来的这个远端分支删了，把新推上来的远端分支名称改成之前删掉的分支名称（即：同名）。

客户端使用 source tree 先拉取新的同名的远端分支代码，在获取新的同名的远端分支代码。

获取代码把下面三个钩选上

关于commit log里面的hash提交记录：删除指定的记录之前的提交记录的Hash维持不变，删除指定的记录之后的提交记录的Hash会重新生成新的。

转：

http://my.oschina.net/u/554046/blog/308614

http://www.01happy.com/git-resolve-conflicts/

详解git pull和git fetch的区别（先要了解git pull和git fetch的区别）

前言

在我们使用git的时候用的更新代码是git fetch，git pull这两条指令。但是有没有小伙伴去思考过这两者的区别呢？有经验的人总是说最好用git fetch+git merge，不建议用git pull。也有人说git pull=git fetch+git merge，真的是这样吗？为什么呢？既然如此为什么git还要提供这两种方式呢？

1. 相同点

首先在作用上他们的功能是大致相同的，都是起到了更新代码的作用。

2. 不同点

先补充一些git里面相关的一些知识：

首先我们要说简单说git的运行机制。git分为本地仓库和远程仓库，我们一般情况都是写完代码，commit到本地仓库（生成本地仓的commit ID，代表当前提交代码的版本号），然后push到远程仓库（记录这个版本号），这个流程大家都熟悉。
我们本地的git文件夹里面对应也存储了git本地仓库master分支的commit ID 和跟踪的远程分支orign/master的commit ID（可以有多个远程仓库）。那什么是跟踪的远程分支呢，打开git文件夹可以看到如下文件：

.git/refs/head/[本地分支]
.git/refs/remotes/[正在跟踪的分支]

其中head就是本地分支，remotes是跟踪的远程分支，这个类型的分支在某种类型上是十分相似的，他们都是表示提交的SHA1校验和（就是commitID）。
但是，不管他们是如何的相似，他们还是有一个重大的区别：
更改远端跟踪分支只能用git fetch，或者是git push后作为副产品（side-effect）来改变。我们无法直接对远程跟踪分支操作，我们必须先切回本地分支然后创建一个新的commit提交。

首先假设我们本地仓库的 master 分支上 commit ID =1 ，orign/mastter中的commit ID =1 ;这时候远程仓库有人更新了github ogirn库中master分支上的代码，新的代码版本号commit ID =2 ,那么在github上 orign/master的commitID=2，然后我们要更新代码。

1. git fetch

使用git fetch更新代码，本地的库中master的commitID不变，还是等于1。但是与git上面关联的那个orign/master的commit ID变成了2。这时候我们本地相当于存储了两个代码的版本号，我们还要通过merge去合并这两个不同的代码版本，如果这两个版本都修改了同一处的代码，这时候merge就会出现冲突，然后我们解决冲突之后就生成了一个新的代码版本。
这时候本地的代码版本可能就变成了commit ID=3，即生成了一个新的代码版本。

相当于fetch的时候本地的master没有变化，但是与远程仓关联的那个版本号被更新了，我们接下来就是在本地合并这两个版本号的代码。

2. git pull

是用git pull更新代码的话就比较简单暴力了，看下图。

使用git pull的会将本地的代码更新至远程仓库里面最新的代码版本

3. 总结

由此可见，git pull看起来像git fetch+get merge，但是根据commit ID来看的话，他们实际的实现原理是不一样的。
这里借用之前文献看到的一句话：

不要用git pull，用git fetch和git merge代替它。
git pull的问题是它把过程的细节都隐藏了起来，以至于你不用去了解git中各种类型分支的区别和使用方法。
当然，多数时候这是没问题的，但一旦代码有问题，你很难找到出错的地方。看起来git pull的用法会使你吃惊，简单看一下git的使用文档应该就能说服你。
将下载（fetch）和合并（merge）放到一个命令里的另外一个弊端是，你的本地工作目录在未经确认的情况下就会被远程分支更新。
当然，除非你关闭所有的安全选项，否则git pull在你本地工作目录还不至于造成不可挽回的损失，但很多时候我们宁愿做的慢一些，也不愿意返工重来。

gitlab处理合并请求：

（dev分支为默认分支，允许所有者合并和所有者推送，不然本地dev处理完也无法提交服务器更改）

设置合并请求之前先运行流水线：

创建合并请求注意不要勾选接受合并请求之后删除源分支

合并请求时自动运行流水线

①运行流水线成功，没有冲突就会直接出现合并按钮，删除源分支要根据实际情况决定选不选。

点击合并按钮之后，运行后续流水线操作

②如果有冲突就需要进行冲突处理：

在服务器上执行将v3.6分支合并到dev分支的操作出现冲突，点本地合并按钮

弹出新的窗口，按照提示做就可以了

注意：本地执行git merge --no-ff "feature-v3.6"命令之后才能把冲突显示出来，本地执行git merge命令是在dev分支上进行的，不是在v3.6分支上进行的。

VS里面的git更改窗口进行合并操作

命令和sourcetree的操作方式参考：

1、 git fetch origin (获取远程所有分支，可以看到本地获取到的变化)
2、 git fetch origin (第二个fetch主要是为了确保本地远程分支为最新，可以不写，)
3、 sourcetree 切换到dev分支并拉取dev分支(等同于命令行里执行 git checkout "dev"，命令执行完后，sourcetree里面本地分支会自动切换到dev上),准备执行下一步合并命令
4、 git merge --no-ff "feature-v3.6"   在本地分支dev上接受本地分支v3.6的合并请求操作之后，命令行里和sourcetree里都能出现冲突
5、visual studio 2019 git更改窗口进行冲突处理
6、sourcetree 提交本地dev分支变化到本地git仓库里的dev分支，（等同于命令行里执行 git push origin "dev"）
7、sourcetree 推送本地git仓库里的dev分支内容到远程dev分支
8、gitlab 刷新页面之后可以看到自动合并成功的界面

刷新gitlab页面后，可以看到合并请求成功之后的界面。

删除github中某个文件夹

git pull origin    #从远程代码仓拉取代码
cd 你要删除的文件夹上一层目录
git rm -r .idea   # -r 参数表示递归删除的意思
git commit -m '删除了.idea'  #提交注释
git push -u origin   #本地代码推送至远程代码仓里

Git和SourceTree一起使用没烦恼（骚）