git知识笔记

#git stash用法总结

常用git stash命令：

（1）git stash save “save message” : 执行存储时，添加备注，方便查找，只有git stash 也要可以的，但查找时不方便识别。

（2）git stash list ：查看stash了哪些存储

（3）git stash show ：显示做了哪些改动，默认show第一个存储,如果要显示其他存贮，后面加stash@{$num}，比如第二个 git stash show stash@{1}

（4）git stash show -p : 显示第一个存储的改动，如果想显示其他存存储，命令：git stash show stash@{$num} -p ，比如第二个：git stash show stash@{1} -p

（5）git stash apply :应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即stash@{0}，如果要使用其他个，git stash apply stash@{$num} ， 比如第二个：git stash apply stash@{1}

（6）git stash pop ：命令恢复之前缓存的工作目录，将缓存堆栈中的对应stash删除，并将对应修改应用到当前的工作目录下,默认为第一个stash,即stash@{0}，如果要应用并删除其他stash，命令：git stash pop stash@{$num} ，比如应用并删除第二个：git stash pop stash@{1}

（7）git stash drop stash@{num} ：丢弃stash@{num}存储，从列表中删除这个存储

（8）git stash clear ：删除所有缓存的stash

说明:新增的文件，直接执行stash是不会被存储的，举例如下：

如上图：在git status 那一步很明显可以看出来，我修改了README，添加了新文件abc.txt，然后执行了git stash save后，在执行git stash list 可以看到刚才的save是的信息，然后使用git stash show ，只显示了README的改动被存起来了。

我们知道，执行了git statsh 以后，被存起来的在当前目录再执行git status 就看不到了，但是我们现在再执行git status，如下：

这个文件还在，说明没有被存起来。说白了就是没有在git 版本控制中的文件，是不能被git stash 存起来的。

那要怎么办呢，这个文件我也想存起来，很明显，先执行下git add 加到git版本控制中，然后再git stash就可以了，如下：

最后一步可以看出来，这个新增文件已经被stash了。

这个时候再执行下git status ,被存起来的在当前目录就看不到了

这个时候，想切分支就再也不会报错有改动未提交了。

如果要应用这些stash，直接使用git stash apply或者git stash pop就可以再次导出来了。

总结下：git add 只是把文件加到git 版本控制里，并不等于就被stash起来了，git add和git stash 没有必然的关系，但是执行git stash 能正确存储的前提是文件必须在git 版本控制中才行。

参考的一个链接中说到了以下，我摘录此处备份下（就是只stash一部分文件）：

​ 常规 git stash 的一个限制是它会一下暂存所有的文件。有时，只备份某些文件更为方便，让另外一些与代码库保持一致。一个非常有用的技巧，用来备份部分文件：

1. add 那些你不想备份的文件（例如： git add file1.js, file2.js）
2. 调用 git stash –keep-index。只会备份那些没有被add的文件。
3. 调用 git reset 取消已经add的文件的备份，继续自己的工作。

#git reset命令

#git 版本回退

git reset：版本回退（建议加上––hard 参数，Git 支持无限次后悔）

• 回退到上一个版本：git reset ––hard HEAD^
• 回退到上上一个版本：git reset ––hard HEAD^^
• 回退到上 N 个版本：git reset ––hard HEAD~N（N 是一个整数）
• 回退到任意一个版本：git reset ––hard 版本号

#git reset —soft,—hard的区别

git reset 命令可以将当前的HEAD重置到特定的状态。 首先要搞清楚下面几个概念

• HEAD: HEAD就是指向当前分支当前版本的游标
• Index: Index即为暂存区，当你修改了你的git仓库里的一个文件时，这些变化一开始是unstaged状态，为了提交这些修改，你需要使用git add把它加入到index，使它成为staged状态。当你提交一个commit时，index里面的修改被提交。
• working tree: 即当前的工作目录。

git reset 的用法 git reset [<mode>] [<commit>] git reset 将当前分支的HEAD指向给定的版本，并根据模式的不同决定是否修改index和working tree。 常用的有三种模式，—soft, —mixed, —hard，如果没有给出则默认是—mixed

—soft

使用--soft参数将会仅仅重置HEAD到制定的版本，不会修改index和working tree

38d65dd (HEAD -> master) Third commit
6bf8706 Second commit
093ceb0 First commit

例如当前分支现在有三次提交，执行git reset --soft HEAD~之后，查看git log

6bf8706 (HEAD -> master) Second commit
093ceb0 First commit

而本地文件的内容并没有发生变化，而index中仍然有最近一次提交的修改，这时执行git status会显示这些修改已经在再暂存区中了，无需再一次执行git add

—mixed

使用--mixed参数与—soft的不同之处在于，—mixed修改了index，使其与第二个版本匹配。index中给定commit之后的修改被unstaged。 如果现在执行git commit 将不会发生任何事，因为暂存区中没有修改，在提交之前需要再次执行git add

—hard

使用--hard同时也会修改working tree，也就是当前的工作目录，如果我们执行git reset --hard HEAD~，那么最后一次提交的修改，包括本地文件的修改都会被清楚，彻底还原到上一次提交的状态且无法找回。所以在执行reset --hard之前一定要小心。

git revert

使用git revert也能起到回退版本的作用，不同之处在于

• git revert <commit>会回退到之前的那次提交，比如git revert HEAD~3会回退到最近的第4个提交的状态，而不是第3个
• git revert会产生一个新的commit，将这次回退作为一次修改记录提交，这样的好处是不修改历史提交记录。

#.gitignore 忽略文件

般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。 通常都是些自动生成的文 件，比如日志文件，或者编译过程中创建的临时文件等。 在这种情况下，我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件的模式。

文件 .gitignore 的格式规范如下：

• 所有空行或者以 # 开头的行都会被 Git 忽略。

• 可以使用标准的 glob 模式匹配，它会递归地应用在整个工作区中。

• 匹配模式可以以（/）开头防止递归。

• 匹配模式可以以（/）结尾指定目录。

• 要忽略指定模式以外的文件或目录，可以在模式前加上叹号（!）取反。

所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。 星号（*）匹配零个或多个任意字符；[abc] 匹配

任何一个列在方括号中的字符 （这个例子要么匹配一个 a，要么匹配一个 b，要么匹配一个 c）； 问号（?）只

匹配一个任意字符；如果在方括号中使用短划线分隔两个字符， 表示所有在这两个字符范围内的都可以匹配

（比如 [0-9] 表示匹配所有 0 到 9 的数字）。 使用两个星号（）表示匹配任意中间目录，比如 a//z 可以

匹配 a/z 、 a/b/z 或 a/b/c/z 等。

我们再看一个 .gitignore 文件的例子：

# 忽略所有的 .a 文件
*.a
# 但跟踪所有的 lib.a，即便你在前面忽略了 .a 文件
!lib.a
# 只忽略当前目录下的 TODO 文件，而不忽略 subdir/TODO
/TODO
# 忽略任何目录下名为 build 的文件夹
build/
# 忽略 doc/notes.txt，但不忽略 doc/server/arch.txt
doc/*.txt
# 忽略 doc/ 目录及其所有子目录下的 .pdf 文件
doc/**/*.pdf

GitHub 有一个十分详细

GitHub 有一个十分详细的针对数十种项目及语言的 .gitignore 文件列表， 你可以在 https://github.com/github/gitignore 找到它。