那些你需要知道的GIT常识

本文认为读者有基本git知识,知道pull push branch的基本用法。在此基础上进行延伸介绍。

首先假设一个场景:A和B都在dev分支开发,A和B在本地都有提交,分别为a和b。此时,A push提交a到服务器,正常提交。然后当B想提交b的时候,Git会提示提交失败,你的分支不是最新的。此时一般人会直接git pull 然后git push,但是你有看过这样产生的git log吗?你会发现,你在git pull 的时候,实际上内部git做了这样的操作:

1 从服务器拉取分支到本地
2执行 git merge 操作

由于有merge操作,所以在看git log 的时候,会发现多了一个merge into XXX的提交记录。如果想不要这个多余的提交,怎么做?git pull -r即可。 执行git pull -r,会在内部执行第二步的时候,从merge变成rebase操作。这样产生的log就会是:根提交——a——b。而不是 根提交——a——b——merge。

rebase命令具体是什么含义?可以看看这篇文章。在我看来,rebase是让git提交记录更加干净清晰。在某些情况下更是有奇效。很多情况下,服务器需要配置数据库、微信支付等敏感信息,或者需要根据环境不同选择执行不同的代码。当然,选择全部做成配置文件然后加入gitignore文件也是一种办法,这里提供另外一种思路:
git仓库中秘钥信息等都为空,部署到服务器之后将信息完善,然后创建提交。开发过程中需要同步服务器的时候,在服务器执行git rebase可以完美更新服务器,不会有烦人的merge信息确认框,让自动部署更加方便。

git reset也是一个很好用的命令。用sourcetree之类的,回滚到某个版本,就是用的这个命令。在看git log的时候,会看到commit后面有串很长的字符串,那就是这个提交的hash值。git reset --hard HASH就可以回退到对应版本去。当你只想回退到上个版本时,还可以用 git reset --hard HEAD^。这里的--hard表示代码也回退到对应版本,否则git reset HEAD^相当于是“撤销上次提交”,版本回退到上个版本,但是代码不变。

git reset HEAD^用在哪里呢?某次提交,发现自己改错文件了,或者提交信息没写,那么可以执行git reset HEAD^,改正后执行git push -f,强制提交,覆盖自己之前的提交。但是注意!git push -f非常非常非常危险!必须保证没有其他人提交的情况下才能用,否则其他人的提交也会被覆盖!

当我想要回退某个文件到某个版本,可以用git checkout HASH FILE。获取对应版本的文件,然后按需要修改即可。

你可能感兴趣的:(那些你需要知道的GIT常识)