git学习记录01

我们大部分人使用git往往就几条命令

git clone
git pull (--rebase)
git add .
git commit -m "log"
git push origin remote
git log
git checkout -- .
git checkout branch_new
git reset HEAD^

虽然对于大部分场景，上述几条命令就已经够用了，但实际上git还有很多的实用用法。下面来逐步讲解。

git reset HEAD

我们暂存文件使用最多的是git add，在工作中往往使用git add .将所有的文件都进行暂存，但有些文件却没必要进行，所以我们可以使用git reset file_name，将其从暂存区移除，由于默认为软回退所以是只是将其从暂存区移除，仍然保留其修改。

对于这个操作解答了我之前的一个疑问，为什么回退默认是从当前分支开始，而不是直接回退到前一笔提交。

git rm

首先，我们常常使用到git add . 是从本地修改文件存储到暂存区，但对于从仓库中直接删除文件的操作却很少用到（日常使用频率也很大），看词义其实也能推测出来是git rm file_name（相当于rm file_name加上git add file_name）

#从本地仓库移除，本地还保留
git rm file_name --cache
git rm . -r --cache
#直接删除，本地也直接删除
git rm file_name -f
git rm . -rf

git config alias.shotcmd "long command"

git中有很多快捷键的操作，可以将长命令以快捷命令的方式输出，对于我们经常使用的命令可以将操作配置为快捷键，这样将会大大节省时间

#配置快捷键
git config alias.ra "rm . -rf"
#使用快捷键
git ra

.gitignore配置

在我们日常使用过程中，常常伴随着git add .将所有文件一起存储到暂存区，但实际上很多中间文件，日志文件往往不需要存储保留（尤其是个人开发时，初始环境没配置好的时候）。

所以需要用到一个文件将我们的中间文件存储进行删选，你当然可以写一个脚本，在每次需要保存的时候剔除所有不需要保存的文件，但git本身就提供了相关的配置，替你省了不少工作。

这个配置就是.gitignore文件，含义也很明确，就是给git设置不追踪的文件，只要在该文件中注明就不会进行追踪

#忽略所有.o或者.a结尾的文件
*.[ao]
#忽略所有.sh结尾的文件build.sh除外
*.sh
!build.sh

git rebase

git rebase是我认为在git中比较好用的一个指令，因为在项目中，不可能是单人进行操作，往往是多人协同，有时候比较难受的一个场景就是，将项目进行到后面，发现前面的某个提交出现了某些细节上的错误（参数有问题，函数声明异常）。这种情况你当然可以通过一笔新的提交，来进行修复。但如果是想让提交路径看着干净一点，可以通过git rebase -i commitid （HEAD~N）来进行交互式修复。

该方法，可以让你很舒服的操作每一笔提交，无论是提交顺序，还是删除（压缩或者拆分）中间部分提交，保留你想要的提交都可以这么操作。

其实对于git add等命令也可使用 -i选项，将暂存变为交互式提交。

git stash

项目中，常常会遇到你正在解决一个问题的时候，突然上司让你解决另一个紧急问题。

这个时候，你往往已经在工作区进行了部分修改，但你又要新去解决紧急问题，你当然可以先branch一个新分支，然后通过add和commit保存你的修改。但还有更好的方式是通过git stash将你的修改存储起来

#存储当前修改
git stash
#查看存储的修改
git stash list
#查看某次存储的修改
git show stash@{N}
#应用某次的修改，默认从最近的开始
git stash apply stash@{N}
#删除某次存储
git stash drop stash@{N}
#应用某次存储并删除
git stash pop stash@{N}

代码追溯

在进行问题定位的时候，常常会看到某行代码你不知道啥意思（可能是问题点），你想知道这笔提交到底是干什么的，谁提交的，什么时候提交的。

最蠢的方法是一条一条去看提交日志，来看是哪笔提交。

如果是想看文件的提交记录，可以使用git log file_name进行查看。

如果是想看文件中的某段修改，可以使用git blame

#查看n行到m行的修改
git blame -L n,m test.txt

当然，直接看代码往往解决不了问题，我们可以通过二分查找的方式来判断哪笔提交有问题（以最近能正常运行的提交作为起点，以最近判断有问题的作为终点，折半回退），这时候当然可以人工手动的进行二分查找，但git其实也帮我集成了这部分操作。

使用git bisect进行二分查找，git bisect start开始启动二分查找，git bisect bad告知当前有问题，git bisect good commitid告知最近好的提交，于是git会给你一笔中间提交，如果验证该提交有问题则标记git bisect bad，反之good，直到最终提示哪笔commit有问题（会有英文打印）。最后通过git bisect reset回到开始的地方。

虽然git bisect的基础使用给我们提供了部分便利，但实际上还是需要我们手动进行验证。于是我们可以在写个脚本每次进行检测，在good场景写0，bad场景非0，这样git bisect start后git bisect run name.sh就可以自动找出是哪里的问题。

公钥位置

在对公司的代码管理系统进行个人初始化配置的时候，有一个比较难受的就是公钥。

需要公钥，是因为大多数 Git 服务器使用 SSH 公钥来授权。之所以难受，是因为我之前常常找不到公钥的位置（id_dsa，id_dsa.pub一个是秘钥，一个是公钥）。

其实公钥特别好找，只需要在windows系统下载git bash，然后通过下面方法生成查看就行（可先ls看有没有，没有再生成）

#生成公钥
ssh-keygen
#查看公钥
ls ~/.ssh/ -la

参考文献：

《Pro Git》