git 的常用命令总结
我平时解决需求用到的,一定不全,日后还会不断补充。。。望路过的哥们,多多提点还是啊!!!
首先是找到一个仓库的链接,有ssh的,有http的,一般都有命令,如:
git clone huoyeben@code.csdn.net.git
后面是远端代码的网址
然后,可能该项目有submodule,github上好像大多没有,你也可以自己建立submodule
有submodule的项目中包含有.gitmodule文件
这时你需要:
git submodule init
先来创建本地的submodule仓库,然后再对本地的submodule仓库来更新
git submodule update
再以后submodule有更新时可以
git submodule foreach git checkout master
git submodule foreach git pull --rebase
当然你也可以cd进单个submodule目录,来手动操作改submodule,与一个普通的仓库无异
有了远端仓库的本地副本,接下来就是做修改了
对任何文件的修改,都会被git记录下来,当然git并不记录,它只对比原本和现在文件的hash值,不一致便是修改过
经常有\t变成了四个空格,或windows与linux下的文件换行符不一致所引发的文件被修改问题。。。
这些在文件系统中被修改的文件还未被收录到git的缓存区,故是红色的,查看变化的命令是:
git status
要将这些修改的文件加入到git的缓存区,要使用
git add -A
一般使用-A表示添加所有修改
这时再查看git的状态,原本的红色修改都变为了绿色,表示被收录到了git的缓存区
一组对文件的修改,往往都有一个目的,这样就可以以这个目的,来对这次的修改进行保存,生成一个commit,可以叫它,结点,版本,变化,修改,提交,whatever。。。
git commit -m "[hot fix] fix:bug3321"
可以像这样生成一个commit,并给这个commit一个注释,方便队友和你以后了解你这次commit的目的
也可以单单
git commit
在而后自动打开的commit_msg中打更多的注释
如果一些变化只是对上一个结点的补充,可以不新生成一个结点,而将新的变化合并到上一个结点,使用
git commit --amend
既然你有了commit,你就要查看历史commit记录了,
git log
可以看到本地的当前分支branch的历史commit链
既然说到了branch,就说一下,分支就是应对不同的需求,每个git一般都会有master分支,一般表示工程目前最稳定的版本
开发会有不同的develop_name分支,来开发各种的不同的功能,当功能稳定时,再将该分支合并到master分支上
查看分支:
git branch
添加分支:
git branch [new_branch_name]
这样不会直接跳转到新创建的分支上去,可以使用
git checkout -b [new_branch_name]
同时创建并跳转到新创建的分支上去
以后可以直接使用
git checkout [branch_name]
来跳转到已有分支
其实checkout 的用法很多可以跳转到打tag的结点等等
下面再来说一下,有了历史记录,如何恢复到历史结点
git reset HEAD~2
这表示回复到当前结点的向上第2个结点,其中HEAD可以理解为是一个结点指针,永远指向当前所在的结点,这里也可以使用结点的commit_id来代替这个指针
commit_id可以在历史链中看到
需要格外注意的是reset分为三种方式:
不加参数,如上:这种方式git的状态将回复到所指的结点状态,文件系统中的文件却并未改变,于是你可以在git status中看到与当前结点不同的未录入的文件修改,红色。。。
加参数
git reset --soft HEAD~1
这种加上soft的方式,文件系统中的文件不会改变,且所有的改变将已经被录入到git的缓存区,故显示为绿色。。。
git reset --hard HEAD
这种加上hard的方式,是平时最常用的,他将文件系统中的文件都硬性改变成当初结点的状态,一键恢复了。。。git status 看不到丝毫改变,谨慎啊!!!
你还可以reset单个文件,只要在最后添加文件的路径及文件名即可,如:
git reset HEAD dir/file
貌似就不能选择其他的参数选项了。。。
那是不是reset --hard 后就再也回不来了呢,也不会如此,还是可以通过
git reflog
来查看最近结点的变化,来找回结点的,其中看得到结点的commit_id,只要通过重新reset 加commit_id就可以恢复回来了
当然,他只记录了结点的变化,没有生成结点的,当然也就永久消失了。。。所以,常生成commit很重要!!!
最后是修改了的结点,上传给同事同步的工作
首先需要检查一下,在你修改代码期间,是否有其他队友也修改了代码
可以直接使用
git pull --rebase
它直接做了fetch和rebase的工作
一般rebase使结点都整齐地排成一条链,而没有分叉,方便查看历史log
fetch是将远程仓库的新的commit在本地接受并生成临时结点的过程
你也可以手动在fetch后,使用merge来生成一个merge结点合并两个一般较远的分叉
在rebase和merge的过程中经常会遇到,你和你的队友同时修改了同一处的代码,这时git将不知道如何合并,于是需要你的手动介入,
你可以在git的提示下,找到产生conflict的文件,打开后并根据自己的实际情况,做出修改,(可以只取一方,也可以保留双方,甚至可以都不要),修改完后记得保存
回到git下,先用add将所作的修改录入到git 的缓存区中,再使用
git rebase --continue
之后就是将自己的修改传上去,如
git push origin HEAD:refs/for/master
其中origin是本地仓库,HEAD是要上传的指针,可以是其他结点
冒号后面是要上传的远端结点的位置
最最后,推荐可视化做的较好的git小白用户软件,smartgit,真的做的挺不错,可以看到结点间文件的变化。。。
望大家批评指正,欢迎补充!!!