通关GitHug之后我收获了什么

.gitignore

*.a

lib.a

能够过滤掉除了lib.a之外所有的.a结尾的文件

git rm —cache filename

remove the file from staging area

git blame filename [1,10]

去查看某文件每一行的最近更新的人 用于blame狗屎代码到底是谁干的

git mv oldfile.txt newfile.txt

rename a file

git add . git commit —amend -m “some message you committed last time”

如果我做了一次提交，然后发现又要改一个文件，和上次的提交想要合并，这里的 commit —amend 就很好用了，

先 add 然后 git commit —amend -m “some message you committed last time”

当然，我们也可以用git reset —soft 到倒数第二次提交，然后重新 git commit -m 也行，不过上面那样就不用 reset了，也就不用重新生成这次提交的hash

git commit -m “add README file” –date “Wen July 26 12:00:00 +0800”

可以在未来的某个时间段提交代码

git reset filename

当我们 git add . 把好多文件都加载到暂存区，然后想让某个文件从暂存区恢复，那么 git reset filename 就可以解决问题

git diff & grep

在做 githug 的第29关点时候，问一个文件被修改了，然后告诉我哪一行被修改了。用 git diff 加各种参数不管用，然后 发现 git grep 这个指令 加上被修改的信息就大概能找出来， git diff 发现那一行被改后是 server.json ，那我就 git grep -n “server.json” 然后就拿到了 26 这个行号. 然后就bingo了

git branch -m oldname newname

35关，问如果 branch 的名字和 tag 的名字相同的话，如果切换到 tag 上。以为 git branch 加上参数比如 -tag 就能切换到 tag 呢，然后发现只能乖乖的把 branch rename 掉，然后再 checkout

git rebase

合并本地特性分支到 master 分支，主分支在前，feature 分支在后

但是每次合并拉取的远程分支时，都是 git rebase upstream/master master ，位置和本地分支的合并法是相反的啊

容我再研究研究

git cherry-pick

在新的分支上写了一堆，好几个commit，然后发现只有其中一个有用，我们想把那次提交合并到当前分支的话，只要切换到当前分支，然后 git cherry-pick 当次提交的hash 如果有冲突的话，解决一下冲突。

git grep “some code”

想查找某个具体的代码，如我想知道项目里有多少个 TODO ，那用 grep 就很简单了

git grep “TODO”

加 -c 会直接指出哪个文件里面有多少个

git rebase -i

如果有一堆 commit ，然后我想修改其中一条的commit message，那这个时候就要用到，git rebase -i

git rebase -i + commit hash(要修改的commit的前一条)，然后在 vim 里面，里面有提示，可以把 pick 改为 reword

同理，如果想合并多个commit到一个上，那在 vim 里面，pick –> squash