git工作中常见使用方法

拉取代码

	git clone http******  

提交代码

  git add .  
  git commit –m “备注”
  git pull   (分支后有|MERGING 拉取发生冲突 )，解决完冲突后 git add .  git commit –m “备注” )  
  git push 

分支

创建分支

git branch 分支名

切换分支

git checkout 分支名

创建分支并切换新分支

 git checkout -b 分支名

删除本地分支

git branch -D 分支名  

删除远程分支

（1）git branch -r -d origin/分支名
（2）git push origin :分支名
如果你的分支是从云端拉取的，这个时候切换回本地的同名分支时，会报				  Switched to branch '分支名' Your branch is based on 'origin/分支名', but the upstream is gone.  (use "git branch --unset-upstream" to fixup)

意思是当前分支上游已经消失

查看本地分支

 git branch 

查看云端分支

git branch -a   标注红色的是云端分支

合并远程分支

现在要把远程的test合并到远程master上面，思路如下：

1. clone项目到本地，此时默认会把master分支clone一份到本地。
   git clone http***** (克隆master分支)
2. 本地分支上新建一个test分支，名字和远程的test一样，复制一份远程test上面的代码，切换到本地master，合并本地test。
   git checkout -b test origin/test （把远程test“复制”到本地）
3. 解决合并过程中的冲突，之后Push到远程master，效果就是远程的test合并到了远程的master上面。
   git merge dev （master合并test分支）
   git push (最后push上去)

将工作区的修改提交到暂存区

   git add -A 保存所有的修改
   git add . 保存新的添加和修改，但是不包括删除
   git add -u 保存修改和删除，但是不包括新建文件。

git stash 保存代码，清理工作区

官方解释：当您想记录工作目录和索引的当前状态，但又想返回一个干净的工作目录时，请使用git
stash。该命令将保存本地修改，并恢复工作目录以匹配头部提交。

stash 命令能够将还未 commit 的代码存起来，让你的工作目录变得干净

git stash   保存代码
git stash apply  恢复代码

# 保存当前未commit的代码
git stash

# 保存当前未commit的代码并添加备注
git stash save "备注的内容"

# 列出stash的所有记录
git stash list

# 删除stash的所有记录
git stash clear

# 应用最近一次的stash
git stash apply

# 应用最近一次的stash，随后删除该记录
git stash pop

# 删除最近的一次stash
git stash drop
复制代码

多条 stash

$ git stash list
stash@{0}: WIP on ...
stash@{1}: WIP on ...
stash@{2}: On ...
复制代码

应用第二条记录：

$ git stash apply stash@{1}
复制代码

pop，drop 同理。

cherry-pick 提交的commit 代码，转移到新分支

将已经提交的 commit，复制出新的 commit 应用到分支里

commit 都提交了，为什么还要复制新的出来？

应用场景1：有时候版本的一些优化需求开发到一半，可能其中某一个开发完的需求要临时上，或者某些原因导致待开发的需求卡住了已开发完成的需求上线。这时候就需要把 commit 抽出来，单独处理。

应用场景2：有时候开发分支中的代码记录被污染了，导致开发分支合到线上分支有问题，这时就需要拉一条干净的开发分支，再从旧的开发分支中，把 commit 复制到新分支。

转移一次 commit 记录
git cherry-pick commitHash 
转移两次 commit 记录
git cherry-pick commitHash1 commitHash2 
转移区间 commit 记录
git cherry-pick commitHash1^..commitHash2 

cherry-pick 代码冲突

1、在 cherry-pick 多个commit时，可能会遇到代码冲突，这时 cherry-pick 会停下来，让用户决定如何继续操作。下面看看怎么解决这种场景。
2、还是 feature 分支，现在需要把 c、d、e 都复制到 master 分支上。先把起点c和终点e的 commitHash 记下来。
3、切到 master 分支，使用区间的 cherry-pick。可以看到 c 被成功复制，当进行到 d 时，发现代码冲突，cherry-pick 中断了。这时需要解决代码冲突，重新提交到暂存区。
4、然后使用 cherry-pick --continue 让 cherry-pick 继续进行下去。最后 e 也被复制进来，整个流程就完成了。

以上是完整的流程，但有时候可能需要在代码冲突后，放弃或者退出流程：

放弃 cherry-pick：

gits cherry-pick --abort

退出 cherry-pick：

git cherry-pick --quit

revert

应用场景：有一天测试突然跟你说，你开发上线的功能有问题，需要马上撤回，否则会影响到系统使用。这时可能会想到用 reset 回退，可是你看了看分支上最新的提交还有其他同事的代码，用 reset 会把这部分代码也撤回了。由于情况紧急，又想不到好方法，还是任性的使用 reset，然后再让同事把他的代码合一遍（同事听到想打人），于是你的技术形象在同事眼里一落千丈。

reflog

应用场景：某天你眼花，发现自己在其他人分支提交了代码还推到远程分支，这时因为分支只有你的最新提交，就想着使用 reset --hard，结果紧张不小心记错了 commitHash，reset 过头，把同事的 commit 搞没了。没办法，reset --hard 是强制回退的，找不到 commitHash 了，只能让同事从本地分支再推一次（同事瞬间拳头就硬了，怎么又是你）。于是，你的技术形象又一落千丈。

撤销git提交

git add . 的本地撤销

git reset HEAD

git commit -m “” 的撤销

 	撤回上一次的提交
	git reset HEAD^ 
	撤回上上次的提交
	git reset HEAD^2  

reset --soft 相当于后悔药，给你重新改过的机会。对于上面的场景，就可以再次修改重新提交，保持干净的 commit 记录。

# 恢复最近一次 commit
git reset --soft HEAD^

以上说的是还未 push 的commit。对于已经 push 的 commit，也可以使用该命令，不过再次 push 时，由于远程分支和本地分支有差异，需要强制推送 git push -f 来覆盖被 reset 的 commit。

git push 成功后撤销

1、首先用 git log 命令查看历史记录（主要是获取版本号）
2、git reset --soft 19462f6f46cf4cbc211d366359afac0c17a7c190
// 注意 --hard 参数会抛弃当前工作区的修改
// 使用 --soft 参数的话会回退到之前的版本，但是保留当前工作区的修改，可以重新提交
3、git push origin master –force （强制提交当前版本号，以达到撤销版本号的目的）