git使用手册,有这些就够了^_^

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Shado_walker/article/details/75212951

日常工作中,有了这些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 <[email protected]>
Date:   Thu Jun 8 20:47:11 2017 +0800


    第三次提交代码


commit 5b9c68b01250a1299956937c28171fd5e59ccf2f
Author: Joven <[email protected]>
Date:   Tue Jun 13 20:41:28 2017 +0800


    第二次提交代码


commit e23aabe78470aae79fff8cc839e1568182581c97
Author: Joven <[email protected]>
Date:   Tue Jun 13 18:06:47 2017 +0800


    第一次提交代码


commit be49d734eb19b65e02a8d34e16c7bfdc9ce21441
Author: Joven <[email protected]>
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更多工作中的实用技巧。*****************/


猜你喜欢

转载自blog.csdn.net/Shado_walker/article/details/75212951
今日推荐