日常工作中，有了这些git命令，解决你代码提交与合并上的痛点，再也不怕代码和别人冲突了，再也不用为合并代码、冲掉别人代码而头痛了。。。
一、clone仓库中的代码
git clone [svn_addr].git，其中[svn_addr].git为代码仓库的地址。
二、提交本地test分支作为远程的master分支
git push origin test:master
三、提交本地test分支作为远程的test分支
git push origin test:test
四、删除远程分支：
git branch -r -d origin/branch-name
git push origin :branch-name
五、创建基于远端的某个分支的本地分支：
git branch -b dev-branch origin/dev-branch
或
git checkout -b dev-branch origin/dev-branch (创建并切换到该分支)
六、将该仓库中的其他分支的提交，合并到当前分支：
git cherry-pick kldsfdkldl(提交的哈希值)
七、改变基板：
git rebase dsfjalkjd(某一版的哈希值)
该命令的应用场景：当本地分支有commit时，如果本地基版落后与远端分支，此时在push代码前，应该做一次git pull去拉一下远端的最新代码，然后将本地的提交push到远端，这时，git实际上是做了两步：1.远端代码拉取到本地后，将本地的那次commit根据时间合并到远端代码上 2.将远端拉取下来的代码与本地落后的代码进行merge，并作一次commit。即本地会产生两次commit，一次是实际自己提交的代码的commit，一次是git自动merge的代码的commit，所以，其实自动merge的那次commit是不需要出现在提交log中的，这时，可以使用git rebase命令将本地那次提交的基版设为拉取下来的最新代码，这样，git就会自动消除他自己产生的那次merge的commit。
八、在使用 Git 作为版本控制的时候，我们可能会由于各种各样的原因提交了许多临时的 commit，而这些 commit 拼接起来才是完整的任务。那么我们为了避免太多的 commit 而造成版本控制的混乱，通常我们推荐将这些 commit 合并成一个:
场景如下：
commit d526a0529901bc47e1fcffab0c87c29dd4df2311
Author: Joven <Joven@qq.com>
Date: Thu Jun 8 20:47:11 2017 +0800
第三次提交代码
commit 5b9c68b01250a1299956937c28171fd5e59ccf2f
Author: Joven <Joven@qq.com>
Date: Tue Jun 13 20:41:28 2017 +0800
第二次提交代码
commit e23aabe78470aae79fff8cc839e1568182581c97
Author: Joven <Joven@qq.com>
Date: Tue Jun 13 18:06:47 2017 +0800
第一次提交代码
commit be49d734eb19b65e02a8d34e16c7bfdc9ce21441
Author: Joven <Joven@qq.com>
Date: Tue Jun 13 18:04:17 2017 +0800
修改XXX情况出现的Bug
其中"第一次提交代码", "第二次提交代码", "第三次提交代码" 三次提交均为"XXX功能的添加"代码，因此，想将这三次提交合并为一次在提交到远端，步骤如下：
（1）git rebase -i be49d734eb19b65e02a8d34e16c7bfdc9ce21441
解释：先将提交 d526a0529901bc47e1fcffab0c87c29dd4df2311，
5b9c68b01250a1299956937c28171fd5e59ccf2f，e23aabe78470aae79fff8cc839e1568182581c97进行合并，则需要将基版变换为最早一次提交的上版，即e49d734eb19b65e02a8d34e16c7bfdc9ce21441。
（2）接下来会进入到vim编辑模式，如下：
pick d526a05
pick 5b9c68b
pick e23aabe
下面还会带有解释（Commands）：
#p, pick = use commit
#r, reword = use commit, but edit the commit message
#e, edit = use commit, but stop for amending
#s, squash = use commit, but meld into previous commit
#f, fixup = like "squash", but discard this commit's log message
#x, exec = run command(the rest of the line) using shell
其中的s(squash)即为将本次提交合并到前一次中，因此，我们将上面的三行修改为：
pick d526a05
s 5b9c68b
s e23aabe
保存退出（:wq）后，会进入输入提交log message的界面，将没有以#开头的行全部删除掉，然后重新起一行写合并后的提交log信息。
（3）然后保存退出。完成以上后，使用git log查看提交的历史信息，即可发现将三次提交合并为一次了。
九、cherry-pick与merge的相同点与区别：
git cherry-pick pickID(提交代码时的唯一哈希值)
相同点：两个都是将一个修改的代码合并到另一个分支上。
不同点：cherry-pick pickID是只将代码仓库中pickID这次提交的修改合并过来，而merge则是将上次更新的代码到现在最新代码之间的差异都进行合并，因此，如果要提交的这次代码与最新代码之间有好几次提交，则可能将无关代码合并过来或者可能会单独出现一版提交merge代码的记录。
十、远端已经删除的分组，在本地依然能看到，可以使用命令：
git remote prune origin
进行清除。
十一、git冲突处理：
1. 在cherry-pick时出现冲突，会报：
error: 不能应用 38e1b4e... XXXXX
提示：冲突解决完毕后，用 'git add <路径>' 或 'git rm <路径>'
此时说明已经冲突了，用git status进行查看，会出现:
要提交的变更：
修改：test.cpp
未合并的路径：
双方修改：xxxx.cpp
此时的代码
没有进行commit，但是已经merge过来，下面会给出的“双方修改：xxxx.cpp”即为冲突的文件名。
编辑冲突的文件xxxx.cpp，文件中介于
<<<<<<<(七个‘<’) HEAD 和 ======= 之间的内容是版本库中的代码，
介于 ======= 和 >>>>>>> 之间的内容是本次自己修改的与版本库代码冲突的代码，可以手动修改这部分代码（即手动解决冲突），手动解决冲突后，执行 git add <文件>标记冲突已解决。
解决完冲突后，执行 git status进行查看，此时已经没有冲突文件了，可以执行git commit进行提交。
十二、git撤销某次commit
找到需要回退的那次commit的 哈希值，执行如下命令：
git reset --hard commit_id
此命令会直接抛弃commit_id之后的所有提交的代码，直接将代码回滚到commit_id.
※技巧：在日程工作中，往往是先使用git checkout -b dev-branch创建一个临时分支，修改好代码后，提交这次修改到本地仓库，然后查看commit ID，然后git checkout到master分支，然后git pull将代码拉取到最新，然后将dev-branch分支修改的代码运用 git cherry-pick commit_ID到主分支，完了之后将dev-branch分支进行删除，再根据最新的代码创建本地de-branch分支，继续进行修改开发。
/******************* 扫描左上角二维码关注公众号，get更多工作中的实用技巧。*****************/
