Git实用指南：忽略文件、命令别名、版本控制、撤销修改与标签管理

1.忽略特殊文件

1.1.那如何配置我们需要忽略的文件的呢？

1.2.如何检验效果？

2.给命令配置别名

3.基本操作之版本回退

3.1.使用场景：

3.2.使用方法：

4.撤销修改

情况一：对于工作区的代码，还没有 add

情况二：已经 add ，但没有 commit

情况三：已经add,并且也commit了

表格总结：

5.基本操作之删除文件

6.标签管理

6.1.理解标签

6.2.创建标签

6.3.操作标签

7.图形化的方式展示分支和合并的历史

1.忽略特殊文件

在日常开发中，我们有些文件不想或者不应该提交到远端，比如保存了数据库密码的配置文件，那怎么让Git知道呢？在Git工作区的根目录下创建⼀个特殊的 .gitignore 文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件了。
不需要从头写 .gitignore 文件，gitee在创建仓库时就可以为我们生成，不过需要我们主动勾选⼀下：

1.1.那如何配置我们需要忽略的文件的呢？

我们只需要vim打开.gitignore文件，将需要忽略的文件后缀书写进去即可。

格式为：

*后缀名

例如我们想忽略以 .so 和 .ini 结尾所有文件， .gitignore 的内容如下：

# My configurations:
*.ini
*.so

当我们想要把一些确定的文件不按照.gitignore规则，

把指定文件排除在 .gitignore 规则外的写法就是 ! +文件名，所以，只需把例外文件添加进去即可。

# 排除所有.开头的隐藏⽂件:
.*
# 不排除.gitignore
!.gitignore

1.2.如何检验效果？

检验 .gitignore 的标准就是 git status 命令是不是说 working tree clean 。我们发现Git并没有提示在工作区中有文件新增，那么 .gitignore 忽略特定文件就生效了！

git check-ignore命令

你发现，可能是 .gitignore 写得有问题，需要找出来到底哪个规则写错了，比如说a.so文件是要被添加的，可以用 git check-ignore 命令检查：

git check-ignore -v a.so
.gitignore:3:*.so a.so

Git会告诉我们， .gitignore 的第3行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。

2.给命令配置别名

在我们使用Git期间，有些命令敲的时候着实让人头疼（太长了。。），幸运的是，git支持对命令进行简化！

举个例子，将 git status 简化为 git st ，对应的命令为：

git config --global alias.st status

--global 参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有用。如果不加，那只针对当前的仓库起作用。

3.基本操作之版本回退

3.1.使用场景：

之前我们也提到，过Git 能够管理文件的历史版本，这也是版本控制器重要的能⼒。如果有⼀天你发现之前的⼯作做的出现了很⼤的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本回退的功能了。

3.2.使用方法：

执⾏ git reset 命令⽤于回退版本，可以指定退回某⼀次提交的版本。要解释⼀下“回退”本质是要将版本库中的内容进⾏回退，⼯作区或暂存区是否回退由命令参数决定：

git reset 命令语法格式为： git reset [--soft | --mixed | --hard] [HEAD]

--mixed 为默认选项，使⽤时可以不⽤带该参数。该参数将暂存区的内容退回为指定提交版本内容，⼯作区⽂件保持不变。
--soft 参数对于⼯作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。
--hard 参数将暂存区与⼯作区都退回到指定版本。切记⼯作区有未提交的代码时不要⽤这个命令，因为⼯作区会回滚，你没有提交的代码就再也找不回了，所以使⽤该参数前⼀定要慎重。
HEAD 说明：可直接写成commit id，表示指定退回的版本

HEAD 表示当前版本
HEAD^ 上一个版本
HEAD^^ 上上一个版本。以此类推...

可以使用 ~数字表示

HEAD~0 表示当前版本:
HEAD~1 上一个版本
HEAD^2 上上一个版本以此类推...

查看历史提交指令

git log --pretty=oneline

可以看到之前版本的commit id用来版本回退。

例如我们可以用下面的指令来回归到version2版本

git log --pretty=oneline
d95c13ffc878a55a25a3d04e22abfc7d2e3e1383 (HEAD -> master) add version3
14c12c32464d6ead7159f5c24e786ce450c899dd add version2
cff9d1e019333318156f8c7d356a78c9e49a6e7b add version1
...git reset --hard 
14c12c32464d6ead7159f5c24e786ce450c899dd

到这里一般回退功能就演示完了，但现在如果我后悔了，想再回到 version3怎么办?我们可以继续使用 git reset 命令，回退到 version 3 版本，但我们必须要拿到 version 3 的 commit id 去指定回退的版本！
但我们看到了 git log并不能打印出 version 3的 commit id ，运气好的话我们可以从终端上去找找之前的记录，运气不好的话 commit id 已经被我们搞丢了。
Git 还提供了一个 git reflog 命令能补救一下，该命令用来记录本地的每一次命令。

git reflog
14c12c3 (HEAD -> master) HEAD@{0}: reset: moving to 
14c12c32464d6ead7159f5c24e786ce450c899dd
d95c13f HEAD@{1}: commit: add version3
14c12c3 (HEAD -> master) HEAD@{2}: commit: add version2
cff9d1e HEAD@{3}: commit: add version1
594da695 HEAD@{4}: commit: add modify ReadMe file
23807c5 HEAD@{5}: commit: add 3 files
c614289 HEAD@{6}: commit (initial): commit my first file

这样，你就可以很方便的找到你的所有操作记录了，但 d95c13f这个是啥东西?这个是 version3 的 commit id 的部分。没错，Git 版本回退的时候，也可以使用部分 commit id 来代表目标版本。

可往往是理想很丰满，现实很骨感。在实际开发中，由于长时间的开发了，导致 commit id 早就找
不到了，可突然某一天，我又想回退到 version3，那该如何操作呢?貌似现在不可能了。。。

4.撤销修改

如果我们在我们的工作区写了很长时间代码，越写越写不下去，觉得自己写的实在是垃圾，想恢复到上⼀个版本。

情况一：对于工作区的代码，还没有 add

我们可以使用 git checkout -- [file]命令让工作区的文件回到最近一次 add 或 commit 时的状态。

要注意 git checkout -- [file]命令中--的很重要，切记不要省略，一旦省略，该命令就变为其他意思了！

情况二：已经 add ，但没有 commit

让我们来回忆一下学过的 git reset 回退命令，该命令如果使用 --mixed 参数，可以将暂存区
的内容退回为指定的版本内容，但工作区文件保持不变。那我们就可以回退下暂存区的内容了!!!

注意--mixed参数是默认参数，是可以省略的。

# --mixed 是默认参数，使⽤时可以省略git reset HEAD ReadMe

情况三：已经add,并且也commit了

不要担心，我们可以 git reset --hard HEAD^ 回退到上一个版本!

不过，这是有前提的，就是你还没有把自己的本地版本库推送到远程。还记得Git是分布式版本控制系统吗?我们后面会讲到远程版本库，一旦你推送到远程版本库，你就真的惨了……

表格总结：

5.基本操作之删除文件

在Git中，删除也是⼀个修改操作，我们实战⼀下,如果要删除 file5文件，怎么搞呢？如果你这样做了:

ls
file1 file2 file3 file4 file5 ReadMe
rm file5

但这样直接删除是没有⽤的，反而徒增烦恼， git status 命令会⽴刻告诉你哪些文件被删除了

此时，工作区和版本库就不一致了，要删文件，目前除了要删工作区的文件，还要清除版本库的文
件。
一般走到这里，有两种可能:

确实要从版本库中删除该文件
不小心删错了

对第二种情况，很明显误删，需要使用 git 来进行恢复，很简单,我们刚学过(删除也是修改):

git checkout -- file5
直接使用这个指令即可。

对于第⼀种情况，很明显是没有删完，我们只删除了⼯作区的⽂件。这时就需要使⽤git rm 将文件从暂存区和⼯作区中删除，并且commit ：

git rm file5

git commit -m"deleted file5"

git rm file5
rm 'file5'
git status
On branch master
Changes to be committed:(use "git restore --staged <file>..." to unstage)deleted: file5
git commit -m"deleted file5"
[master 5476bde] deleted file51 file changed, 0 insertions(+), 0 deletions(-)delete mode 100644 file5
git status
On branch master
nothing to commit, working tree clean

现在，文件就从版本库中被删除了

6.标签管理

6.1.理解标签

标签 tag ，可以简单的理解为是对某次 commit 的一个标识，相当于起了一个别名。例如，在项目
发布某个版本的时候，针对最后一次 commit 起一个 v1.0 这样的标签来标识里程碑的意义。
这有什么用呢?相较于难以记住的 commit id ,tag 很好的解决这个问题，因为 tag 一定要给
个让人容易记住，且有意义的名字。当我们需要回退到某个重要版本时，直接使用标签就能很快定位到。

6.2.创建标签

在Git中打标签非常简单，首先，切换到需要打标签的分支上

然后，敲命令 git tag [name] 就可以打⼀个新标签：

可以⽤命令 git tag 查看所有标签：

默认标签是打在最新提交的 commit 上的。那如何在指定的commit上打标签呢？⽅法是找到历史提交的commit id，然后打上就可以了，⽰例如下：

# 历史记录
hyb@139-159-150-152:~/git_teaching$ git log --pretty=oneline --abbrev-commit
97811ab (HEAD -> master, tag: v1.0, origin/master, origin/HEAD) add .gitignore
60e6b0a update README.md.
7ce3183 create file.txt
c6ce3f0 Initial commit
# 对 Initial commit 这次提交打标签
hyb@139-159-150-152:~/git_teaching$ git tag v0.9 c6ce3f0
hyb@139-159-150-152:~/git_teaching$ git tag
v0.9
v1.0

注意，标签不是按时间顺序列出，而是按字母排序的。
可以用 git show [tagname]查看标签信息。

6.3.操作标签

如果标签打错了，也可以删除

git tag -d [tagname]

hyb@139-159-150-152:~/git_teaching$ git tag 
v0.9
v1.0
hyb@139-159-150-152:~/git_teaching$ git tag -d v0.9 
Deleted tag 'v0.9' (was c6ce3f0)
hyb@139-159-150-152:~/git_teaching$ git tag 
v1.0

因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
如果要推送某个标签到远程，使用命令 git push origin <tagname>

如果标签已经推送到远程，要删除远程标签就⿇烦⼀点，先从本地删除；然后，从远程删除。删除命令也是push，但是格式如下：

hyb@139-159-150-152:~/git_teaching$ git tag
v1.0
hyb@139-159-150-152:~/git_teaching$ git tag -d v1.0 
Deleted tag 'v1.0' (was 97811ab)
hyb@139-159-150-152:~/git_teaching$ git push origin :refs/tags/v1.0
remote: Powered by GITEE.COM [GNK-6.4]
To gitee.com:hyb91/git_teaching.git- [deleted] v1.0