故事的主角是小明,一个刚入门编程的小白。他正在为一个项目写代码,但是他发现每次修改代码都很麻烦,因为他要不断地备份文件,而且很容易弄混版本。有一天,他听说了一个叫 Git 的神奇工具,可以帮助他管理代码的变化。他决定尝试一下,于是他打开了终端,输入了下面的命令:
git init # 初始化一个本地仓库
git add . # 添加所有文件到暂存区
git commit -m "first commit" # 提交第一次修改到本地仓库
这样,他就成功地创建了一个 Git 仓库,并且保存了他的第一个版本。他觉得很开心,因为这样他就不用担心代码丢失或者混乱了。😁
小明觉得自己的代码写得很不错,想要分享给其他人看看。但是他发现把文件发给别人很麻烦,而且如果别人也修改了代码,就很难合并。有一天,他听说了一个叫 GitHub 的网站,可以免费托管 Git 仓库,并且方便和其他人协作。他决定尝试一下,于是他注册了一个 GitHub 账号,并且在网站上创建了一个空的仓库。
然后,他在终端输入了下面的命令:
git remote add origin https://github.com/xiaoming/myproject.git # 添加远程仓库地址
git push -u origin master # 推送本地 master 分支到远程仓库
这样,他就成功地把自己的代码上传到了 GitHub 上,并且和远程仓库建立了联系。他觉得很兴奋,因为这样他就可以和全世界的程序员交流了。😍
小明在 GitHub 上发现了一个很有趣的开源项目,想要参与其中。但是他不想直接修改别人的代码,而是想先在自己的电脑上做一些改进,然后再提交给项目的作者。有一天,他听说了一个叫分支的概念,可以让他在不影响主线的情况下,创建自己的代码版本。他决定尝试一下,于是他在终端输入了下面的命令:
git clone https://github.com/someone/awesome-project.git # 从远程仓库克隆项目到本地
cd awesome-project # 进入项目目录
git checkout -b dev # 创建并切换到 dev 分支
这样,他就成功地在本地创建了一个 dev 分支,并且和远程仓库的 master 分支分开了。他觉得很自由,因为这样他就可以随心所欲地修改代码了。😎
小明在 dev 分支上修改了一些代码,觉得很满意,想要把自己的改进合并到 master 分支上,然后推送到远程仓库,让项目的作者看看。有一天,他听说了一个叫合并的操作,可以把两个分支的代码合并成一个。他决定尝试一下,于是他在终端输入了下面的命令:
git checkout master # 切换到 master 分支
git merge dev # 合并 dev 分支到 master 分支
git push origin master # 推送 master 分支到远程仓库
这样,他就成功地把自己的代码合并到了 master 分支,并且推送到了远程仓库。他觉得很骄傲,因为这样他就可以为开源项目做出贡献了。😊
但是,有时候合并分支并不是一帆风顺的。有一次,小明在 dev 分支上修改了一个文件,而项目的作者也在 master 分支上修改了同一个文件,并且先于小明推送到了远程仓库。当小明想要合并分支时,就发生了冲突。有一天,他听说了一个叫解决冲突的方法,可以手动选择保留哪些代码。他决定尝试一下,于是他在终端输入了下面的命令:
git pull origin master # 拉取远程仓库的 master 分支
git merge master # 合并 master 分支到 dev 分支
# 打开冲突文件,编辑保存
git add . # 添加所有文件到暂存区
git commit -m "fix conflict" # 提交修改到本地仓库
git push origin dev # 推送 dev 分支到远程仓库
这样,他就成功地解决了冲突,并且把自己的代码推送到了远程仓库。他觉得很成就感,因为这样他就可以和其他人协作了。😄
小明在 dev 分支上开发了一个新功能,觉得很完美,想要给这个版本打一个标签,方便以后查找。有一天,他听说了一个叫标签的概念,可以给某个版本起一个有意义的名字。他决定尝试一下,于是他在终端输入了下面的命令:
git tag v1.0 # 给当前版本打一个 v1.0 的标签
git push origin v1.0 # 推送标签到远程仓库
这样,他就成功地给自己的代码打了一个标签,并且推送到了远程仓库。他觉得很方便,因为这样他就可以快速定位到某个版本了。😎
但是,有时候有些文件是不需要被 Git 管理的,比如编译生成的临时文件,或者敏感信息的配置文件。有一天,他听说了一个叫忽略特殊文件的方法,可以让 Git 自动忽略掉这些文件。他决定尝试一下,于是他在项目根目录下创建了一个.gitignore 文件,并且写入了下面的内容:
*.tmp # 忽略所有.tmp 后缀的文件
config.ini # 忽略 config.ini 文件
这样,他就成功地让 Git 忽略掉了这些特殊文件,并且不会被提交到仓库中。他觉得很安全,因为这样他就可以避免泄露隐私或者浪费空间了。😊
小明和小红是一个团队的成员,他们都在 GitHub 上为同一个开源项目贡献代码。有一天,小明在本地修改了一个文件的名字,把它从 README.md 改成了 Readme.md ,然后提交并推送到了远程仓库。小红在自己的电脑上拉取了最新的代码,但是她发现自己的文件名还是 README.md ,而且 Git 提示她有一个未合并的文件。她很困惑,不知道为什么会出现这样的情况。
原来,这是因为 Git 在不同的操作系统上对文件名大小写的敏感度不同。在 Linux 和 Mac OS X 上,Git 是区分大小写的,所以 README.md 和 Readme.md 是两个不同的文件。但是在 Windows 上,Git 是不区分大小写的,所以 README.md 和 Readme.md 是同一个文件。当小明把文件名改成了 Readme.md 时,Git 认为他删除了 README.md ,并且创建了一个新的文件 Readme.md 。当小红拉取代码时,Git 认为她需要合并这两个文件,所以出现了冲突。
有一天,他们听说了一个叫解决大小写不一致导致的合并冲突的方法,可以让 Git 在 Windows 上也区分大小写。他们决定尝试一下,于是他们在终端输入了下面的命令:
git config core.ignorecase false # 设置 Git 在 Windows 上也区分大小写
git mv README.md Readme.md # 重命名文件
git commit -m "rename file" # 提交修改
git push origin master # 推送到远程仓库
这样,他们就成功地解决了大小写不一致导致的合并冲突,并且保持了文件名的一致性。他们觉得很开心,因为这样他们就可以避免以后出现同样的问题了。😁
小明和小红在开发一个新功能时,不小心提交了一些错误的代码,导致项目无法运行。他们想要撤销这些提交,但是又不想丢失他们的修改。有一天,他们听说了一个叫 reset 的命令,可以让他们回退到某个版本,但是保留他们的修改。他们决定尝试一下,于是他们在终端输入了下面的命令:
git reset HEAD~2 # 回退到两个版本之前,保留修改
git status # 查看修改的状态
git add . # 重新添加修改到暂存区
git commit -m "fix bug" # 重新提交修改
git push -f origin master # 强制推送到远程仓库
这样,他们就成功地撤销了错误的提交,并且重新提交了正确的代码。他们觉得很轻松,因为这样他们就可以修复 bug 了。😊
但是,有时候 reset 命令也会带来麻烦。有一次,小明在回退版本时,不小心加了一个–hard 选项,导致他的修改全部丢失了。他很慌张,不知道如何找回他的修改。有一天,他听说了一个叫 reflog 的命令,可以让他查看所有的提交历史,包括已经被删除或者回退的提交。他决定尝试一下,于是他在终端输入了下面的命令:
git reflog # 查看所有的提交历史
git reset --hard c761f5c # 回退到指定的版本
git status # 查看修改的状态
这样,他就成功地找回了他丢失的修改,并且恢复到了正确的版本。他觉得很幸运,因为这样他就可以继续开发了。😄
小明和小红在同一个分支上开发一个新功能,他们经常需要拉取对方的代码,然后合并到自己的代码中。有一天,他们听说了一个叫 pull 的命令,可以让他们一步完成拉取和合并的操作。他们决定尝试一下,于是他们在终端输入了下面的命令:
git pull origin master # 拉取并合并远程仓库的 master 分支
这样,他们就成功地把对方的代码合并到了自己的代码中,并且保持了同步。他们觉得很方便,因为这样他们就可以避免手动合并的麻烦了。😎
但是,有时候 pull 命令也会带来问题。有一次,小明和小红在同一个文件上修改了同一行代码,导致出现了冲突。他们很困惑,不知道如何解决这个冲突。有一天,他们听说了一个叫解决冲突的方法,可以让他们手动选择保留哪些代码。他们决定尝试一下,于是他们在终端输入了下面的命令:
git pull origin master # 拉取并合并远程仓库的 master 分支
# 打开冲突文件,编辑保存
git add . # 添加所有文件到暂存区
git commit -m "merge conflict" # 提交修改到本地仓库
git push origin master # 推送到远程仓库
这样,他们就成功地解决了冲突,并且把自己的代码推送到了远程仓库。他们觉得很成就感,因为这样他们就可以和对方协作了。😄
小明和小红在同一个项目上开发不同的功能,他们分别在自己的分支上提交了一些代码。有一天,他们想要把自己的代码合并到主分支上,但是他们不知道应该用 rebase 还是 merge 。有一天,他们听说了一个叫 rebase 和 merge 的区别的概念,可以让他们选择合适的方式来合并代码。他们决定尝试一下,于是他们在终端输入了下面的命令:
# 小明在 dev1 分支上
git checkout dev1 # 切换到 dev1 分支
git rebase master # 把 dev1 分支变基到 master 分支
git push -f origin dev1 # 强制推送 dev1 分支到远程仓库
git checkout master # 切换到 master 分支
git merge dev1 # 合并 dev1 分支到 master 分支
git push origin master # 推送 master 分支到远程仓库
# 小红在 dev2 分支上
git checkout dev2 # 切换到 dev2 分支
git merge master # 合并 master 分支到 dev2 分支
git push origin dev2 # 推送 dev2 分支到远程仓库
git checkout master # 切换到 master 分支
git merge dev2 # 合并 dev2 分支到 master 分支
git push origin master # 推送 master 分支到远程仓库
这样,他们就成功地把自己的代码合并到了主分支上,但是他们发现了一个不同的地方。小明用了 rebase 命令,他的提交历史是一条直线,没有任何分叉;小红用了 merge 命令,她的提交历史是有多个分叉和汇合的结构。他们觉得很好奇,不知道这两种方式有什么优缺点。
原来,rebase 和 merge 的区别是:
rebase 和 merge 各有优缺点:
所以,在选择 rebase 还是 merge 时,要根据具体的情况和需求来决定。一般来说:
小明和小红在合并分支时,不小心合并了错误的分支,导致项目出现了很多 bug 。他们想要撤销这次合并,但是又不想丢失他们的修改。有一天,他们听说了一个叫 revert 的命令,可以让他们用一次新的提交来回滚之前的提交。他们决定尝试一下,于是他们在终端输入了下面的命令:
git log # 查看提交历史
git revert <commit ID> # 回滚指定的提交
git push origin master # 推送到远程仓库
这样,他们就成功地撤销了错误的合并,并且用一次新的提交来记录这次回滚。他们觉得很安全,因为这样他们就不会丢失任何修改了。😊
但是,有时候 revert 命令也会带来麻烦。有一次,小明在回滚一个合并时,不小心加了一个–no-commit 选项,导致他的修改没有被提交,而是被放在了暂存区。他很慌张,不知道如何恢复这次回滚。有一天,他听说了一个叫 reset 的命令,可以让他回退到某个版本,并且保留或者丢弃他的修改。他决定尝试一下,于是他在终端输入了下面的命令:
git reset --soft HEAD^ # 回退到上一个版本,并且保留修改
git status # 查看修改的状态
git add . # 重新添加修改到暂存区
git commit -m "fix bug" # 重新提交修改
git push -f origin master # 强制推送到远程仓库
这样,他就成功地恢复了这次回滚,并且重新提交了正确的代码。他觉得很轻松,因为这样他就可以修复 bug 了。😊
小明和小红在完成一个功能后,想要删除自己的分支,因为他们觉得这个分支已经没有用了。有一天,他们听说了一个叫 delete 的命令,可以让他们删除本地或者远程的分支。他们决定尝试一下,于是他们在终端输入了下面的命令:
git branch -d dev1 # 删除本地的 dev1 分支
git push origin --delete dev1 # 删除远程的 dev1 分支
这样,他们就成功地删除了自己的分支,并且释放了一些空间。他们觉得很爽快,因为这样他们就可以开始新的功能了。😎
但是,有时候 delete 命令也会带来后悔。有一次,小明在删除一个分支后,发现自己还需要这个分支上的一些代码。他很懊恼,不知道如何找回这个分支。有一天,他听说了一个叫 reflog 的命令,可以让他查看所有的提交历史,包括已经被删除或者回退的提交。他决定尝试一下,于是他在终端输入了下面的命令:
git reflog # 查看所有的提交历史
git checkout -b dev1 <commit ID> # 用指定的提交创建一个新的 dev1 分支
git push origin dev1 # 推送 dev1 分支到远程仓库
这样,他就成功地找回了自己的分支,并且恢复到了正确的版本。他觉得很幸运,因为这样他就可以继续使用这个分支了。😄
到此为止,我已经给你讲完了小明和小红的故事,你觉得怎么样?👏
1
mineralsalt 2023-06-13 08:43:30 +08:00 35
懂得人不会看, 不会的人看不懂
|
2
GTim 2023-06-13 08:55:49 +08:00 3
其实还是蛮有用的
|
3
Victor215 2023-06-13 08:59:51 +08:00 1
git 个人感觉还是要 GUI 操作,啥撤销恢复啥的的命令根本记不住。
|
4
JustW OP @mineralsalt 哈哈,适合刚入门的看一下大体的使用流程.
|
7
HankLu 2023-06-13 09:05:42 +08:00 6
@mineralsalt 胡扯,这对似懂非懂的人非常有用,感谢楼主的帖子,收藏了。
|
8
someonesnone 2023-06-13 09:08:06 +08:00 via iPhone
有跟乌龟一样的图形界面吗 记不住命令行
|
9
wjx0912 2023-06-13 09:10:21 +08:00
弱弱的提个 bug:
git push -u origin master ---> git push -u origin main |
10
russ44 2023-06-13 09:22:36 +08:00
cool
|
11
xiangyuecn 2023-06-13 09:22:41 +08:00 1
|
12
Liuman 2023-06-13 09:25:44 +08:00
学习了,谢谢
|
13
fishworm 2023-06-13 09:32:17 +08:00
写的不错,支持一下。
|
14
wsssss 2023-06-13 09:32:26 +08:00
从来不用 git push -f 感觉强推太危险。我 rebase 时都是单拉分支再 push 。
|
16
zhhqiang 2023-06-13 09:57:13 +08:00
给 解决 windows 区分 大小写 点赞,之前都是删了重新提交。
|
17
ql562482472 2023-06-13 09:58:02 +08:00 1
@someonesnone #8 有 看命令行的都是大神 我们小白还是 UI 把 Idea 那种简洁 UI 就是最简单的
|
18
season8 2023-06-13 10:03:32 +08:00
挺好的,配合应用场景,特别适合入门和囫囵吞枣的
|
19
ztc 2023-06-13 10:16:53 +08:00
👍🏻
|
20
november 2023-06-13 10:22:22 +08:00
虽然但是,mac os 默认也是不区分大小写的。这估计又是哪里复制黏贴的。
|
21
mingsi 2023-06-13 10:24:07 +08:00 via Android
可能是我见识短,这是我见过的最好的中文 git 入门简介了!
|
22
miaotaizi 2023-06-13 10:24:22 +08:00
小明跟小红最后在一起了吗?
第二季什么时候出? |
23
zoezz 2023-06-13 10:29:24 +08:00
不错👏
|
24
keepro 2023-06-13 10:37:57 +08:00
对于我来说,我还是挺喜欢这种教程的,在熟悉的过程中,再看详细的命令介绍,会有很大的进步。感谢分享~
|
25
we21x 2023-06-13 10:40:26 +08:00
补充一个 git stash 指令:
小明在本地开发一个新功能的时候需要修改本地的配置文件,但是这个修改只能保存在本地,而且每次开发新功能的时候都需要修改本地的配置文件。小明不想每次都手动修改配置文件,有一天小红告诉他一个叫 stash 的指令,可以将本地的修改丢弃并保存在 git 中,然后通过 git stash pop 恢复最近一次的修改、git stash apply <idx> 恢复某一次修改的内容,这样小明就无需每次都手动修改配置文件了,他觉得很开心( doge ;另外这个指令切分支的时候也很有用~ |
26
placeholder 2023-06-13 11:03:16 +08:00
写的很好,抄走…不是…收藏了
|
27
remember5 2023-06-13 11:04:02 +08:00 1
|
28
wayne3602 2023-06-13 11:05:26 +08:00 via Android
现在一般都是 main 分支了吧,建议改一下
|
31
Baoni 2023-06-13 11:10:03 +08:00
谢谢,最近有不会的操作都在问 gpt 了
|
32
daimubai 2023-06-13 11:14:12 +08:00
@wjx0912 github 是可以修改 main 为 master 的,像公司一般搭建 git 的话也还是 master 。而且 git 本身的主分支就是 master
|
33
JustW OP @someonesnone 有的,很多.我一般用的 idea 自带的.或者是 GitKraken 这款也行.
|
35
xiaojianghu 2023-06-13 11:36:55 +08:00
“如果你想要在公共的分支上合作,你应该用 merge ,避免用 rebase ,因为 rebase 会改变提交历史,可能导致其他人的困扰”,rebase 真的会给别人带来困扰吗
|
36
magicls 2023-06-13 11:41:18 +08:00
支持一下,个人觉得其实写得挺好的。
|
37
baiyi 2023-06-13 11:42:50 +08:00
对刚接触的人来说还是挺不错的,结合了场景来教命令。对于想要深入一点学习 git 的人来说,推荐 《 Pro Git 》
|
38
JustW OP @xiaojianghu 这块主要针对多人开发时,可能会因为历史顺序的变动,导致其他人更新时需要额外了解.merge 的话,每个人提交记录更清晰.
|
40
wellerman 2023-06-13 12:08:10 +08:00
挺好,总结的不错。
|
41
mrzx 2023-06-13 12:32:39 +08:00
写的非常好
|
43
xiaojianghu 2023-06-13 12:39:16 +08:00 1
@JustW #38 我在工作中更多的使用 rebase ,我感觉 rebase 的提交就像直接在主分支上提交的一样,看不出来是否开了一个新分支并将提交合到主分支,merge 可以看到这个过程,所以 rebase 更容易产生冲突吗
|
44
AlexBirmingham 2023-06-13 12:42:39 +08:00
@wjx0912 ??我学习的是 GUI 的默认是 main ,git 默认是 master 。 博主就是练习命令行操作,master 没有错啊,main 才不对
|
45
xabcstack 2023-06-13 12:51:01 +08:00
git pull && git push 梭哈,其他都是浮云
|
46
zq11211277 2023-06-13 12:54:49 +08:00
@mineralsalt #1 哈哈 说的没错 适合二懂二懂的看
|
47
JustW OP @xiaojianghu 这块我不知道怎么表达,大概就是个人开发的话,用 rebase 可以让自己看历史记录更清晰,但是当合并主分支的时候,用 merge 让其他人看起来跟清晰, 最后还是看个人使用习惯吧.并没有说哪种就不行.哈哈. 另外冲突实际上两种方式都会出现.
|
48
JustW OP @xiaojianghu 可以看下这个网站的讲解,比我写的更加深刻,全面!https://www.atlassian.com/git/tutorials/merging-vs-rebasing
|
49
xiaojianghu 2023-06-13 13:40:30 +08:00
@JustW #48 好的,感谢
|
50
bojackhorseman 2023-06-13 14:10:47 +08:00
提到大小写敏感,如果你直接把 `user.vue` 改成 `User.vue`, git 默认会认为没变化,但你本地的编辑器会感知到,于是你修改了文件引入,但推到线上别人一拉,发现文件名还是小写的,编译失败,文件引入找不到🤣。
我有一个文件名改大小写的小妙招,先把文件名改成别的,再改大写就可以了: git mv user.vue userA.vue git mv userA.vue User.vue |
51
jackshen 2023-06-13 14:13:54 +08:00
赞👍 又 get 到了一些新技巧
|
52
lasuar 2023-06-13 14:36:20 +08:00
多年开发,对于 git 也只是熟悉常用指令,看了楼主的文字后终于熟悉了 rebase 、reflog ,非常感谢啊~~~
|
53
wangqiKylin 2023-06-13 14:39:34 +08:00
不错,给 op 点个赞,先马再看
|
54
fox233 2023-06-13 14:48:20 +08:00
新版本 Git 切换分支是 git switch
|
55
nullpoint007 2023-06-13 15:43:20 +08:00
收藏
|
57
MRG0 2023-06-13 15:49:20 +08:00 1
@someonesnone Git Extensions
|
58
zhengkk 2023-06-13 15:53:14 +08:00
简单问题复杂化
|
59
pkoukk 2023-06-13 16:02:02 +08:00
挺好的,但是对小白我都直接推荐 GUI
|
60
JustW OP @pkoukk 是的,现在一般都用的 GUI,这个文章也就是让大家了解下有这么个命令,真要研究,肯定还要找别的资料学习的.
|
61
Vclow 2023-06-13 16:25:52 +08:00
GUI 还是方便很多,偶尔用命令
|
62
chenalex 2023-06-13 16:31:47 +08:00
|
64
Margelator 2023-06-13 16:53:25 +08:00
不会的人直接卡在第一步
|
65
Cursor1st 2023-06-13 17:09:22 +08:00
学到了学到了,很不错,感谢
|
66
justin2018 2023-06-13 17:26:57 +08:00
以前只会 git add . ---> git commit "xxxxxx" ---> git push
后来项目中遇到各种需求 就学会了 更多的技能 😁 |
67
Biluesgakki 2023-06-13 17:30:04 +08:00
我还是喜欢用命令 。另外可以加一个 git commit --amend
|
68
JustW OP @justin2018 哈哈,我也是,经常用的也就这几个,加上合并
|
69
JustW OP @Biluesgakki 这个命令在我博客的另外一篇文章里有写,
|
70
hitmanx 2023-06-13 17:51:47 +08:00
支持一下,谢谢分享
|
71
huitailangcy 2023-06-13 17:59:22 +08:00
牛逼,感谢分享
|
72
7gugu 2023-06-13 18:05:47 +08:00
感觉还是得靠实践才记得住😂,不过 OP 的分享很有用👍
|
73
XxxxD 2023-06-13 18:25:56 +08:00
很不错,感谢分享,之前看过 progit 太详细了,你写的很形象很好记忆
|
74
lingalonely 2023-06-13 19:00:16 +08:00
挺好的,基本可以覆盖 80 ~ 90%的使用场景,就有些特殊情况没提及 比如 stash 的情况
|
75
leeton 2023-06-13 19:24:02 +08:00 via iPhone
我自始至终就会一个命令,就是 git clone 。其余的都是用 idea 提交的,手比较残🥲
|
76
TomPig0216 2023-06-13 20:44:21 +08:00
感谢分享哈哈 温故而知新了属于是
|
77
hhjswf 2023-06-13 22:21:49 +08:00 via Android
话说,按照你的解释,rebase 和 merge 根本不是一回事啊没什么好比较的。rebase 是变基,最后合并还是用 merge 。
|
78
hhjswf 2023-06-13 22:24:10 +08:00 via Android
@xiaojianghu 你这样为什么不直接在主分支上开发提交?
|
79
WisdomDevil 2023-06-14 00:56:51 +08:00 via Android
谢谢楼主用简明的方式解释~
|
80
liberty1900 2023-06-14 03:44:57 +08:00
现在的年轻人,第 6 天就碰上大小写敏感问题,第 9 天就开始 rebase 啦
何时学习 git push -f 捏 |
81
liberty1900 2023-06-14 03:46:34 +08:00
@liberty1900 好吧,第 7 天就有了
|
82
jqtmviyu 2023-06-14 09:13:19 +08:00
|
83
jqtmviyu 2023-06-14 09:13:39 +08:00
|
84
Eliven 2023-06-14 09:26:58 +08:00
|
86
Aaron01 2023-06-14 10:01:33 +08:00 via Android
太好了
|
87
shaozelin030405 2023-06-14 10:04:59 +08:00
自己用 gui 搞。。。好伐
|
88
yuanxin1999 2023-06-14 10:40:47 +08:00
@wjx0912
想到了 Yandex 的 master 和 nigger😂 |
89
Vanderick 2023-06-14 11:37:31 +08:00
写得挺好的~ 赞
|
90
xiaojianghu 2023-06-14 16:45:18 +08:00
@hhjswf #78 习惯了开新分支修 bug 或写需求
|
91
Meonardo 2023-06-16 13:12:21 +08:00 via iPhone
🇰🇷🇰🇷🇰🇷
|
92
qqqyh 2023-06-26 13:44:21 +08:00
第一次知道 windows 上 git 不区分大小写
|