注意事项与声明
平台: Windows 10
作者: JamesNULLiu
邮箱: jamesnulliu@outlook.com
博客: https://www.cnblogs.com/jamesnulliu
学习笔记 转载请注明出处 欢迎留言
0. 前言
本系列文章是 git & github 的入门教程.
本系列文章优势:
- 零基础
深入浅出
知识点涵盖面广
本系列其他文章的链接
尽管如此, 想要真正学会 git & github 建议不要看任何教程, 直接看 git 的 官方文档.
1. [rm] 删除文件
- 当 远程储存库, git储存库 和 本地文件夹 内都存在相同的文件 "a.bbb", 并且 想彻底从储存库中删除这个文件.
先用 git rm 删除文件 (直接在文件夹内右键删除也行):
$ git rm a.bbb
查看状态:
$ git status
On branch master
Your branch is up to date with 'origin/main'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
deleted: a.bbb
这里注意, 根据他的提示, 如果错误地 add 了某文件 (例如 "c.ddd") 到 staged area, 就用命令 git restore --staged c.ddd 取消添加.
接着不用 add, 只需要 commit 和 push.
$ git commit -m "<message>"
$ git push origin main
这样这个文件就被同时从本地和远程删除了.
[不建议] 当 git储存库 和 本地文件夹 内存在文件 "a.bbb" 但不相同 (就是先前 commit 了这个文件到 git repository 之后本地又进行了修改), 并且想彻底从 远程 和 git储存库 还有本地 工作文件夹 中删除这个文件.
这种情况需要强制删除 (force):
$ git rm -f "a.bbb"
$ git commit -m "<message>"
$ git push origin main
当 远程储存库, git储存库 和 本地文件夹 内都存在相同的文件 "a.bbb", 而 只想删除 远程 和 git储存库 中的文件, 并将文件保留在本地 工作文件夹.
使用 git rm --cached <file>:
$ git rm --cached a.bbb
$ git commit -m "<message>"
$ git push origin main
2. .gitignore 的使用
实际开发过程中, 我们经常会希望不要将项目运行过程中生成的一些中间文件, 日志文件, 生成文件等同步到储存库里.
比如用 visual stutdio 编译并生成一段代码, 工作文件夹内会出现一些 .log 呀, .obj 呀这样的文件. 这些文件对版本管理来说可能没有很大的用处.
尽管我们可以用 git status 配合 git add <file> 一个个将自己想要推送到储存库的文件打到命令行里, 但如果面对一个很大的项目, 要添加非常多文件, 这样效率会十分低.
我们还需要知道, 下面的命令可以将 git status 输出显示的所有改动/新增的文件添加的 staged area 中:
git add .
这就是为什么我们应该写一个 ".gitignore" 文档, 用来让 git 知道哪些文件或文件夹应该被 untracked, 然后选择性地用 git add . 快速添加文件.
.gitignore 文件应该在 working tree 的最高层创建. 打开项目文件夹后, 右键新建文本文档, 吧文件名和 ".txt" 全删了只保留 ".gitignore".
以下是完整的书写规则:
A blank line matches no files, so it can serve as a separator for readability.
A line starting with # serves as a comment. Put a backslash (" \ ") in front of the first hash for patterns that begin with a hash.
Trailing spaces are ignored unless they are quoted with backslash (" \ ").
An optional prefix " ! " which negates the pattern; any matching file excluded by a previous pattern will become included again. It is not possible to re-include a file if a parent directory of that file is excluded. Git doesn’t list excluded directories for performance reasons, so any patterns on contained files have no effect, no matter where they are defined. Put a backslash (" \ ") in front of the first " ! " for patterns that begin with a literal " ! ", for example, "!important!.txt".
The slash / is used as the directory separator. separators may occur at the beginning, middle or end of the .gitignore search pattern.
If there is a separator at the beginning or middle (or both) of the pattern, then the pattern is relative to the directory level of the particular .gitignore file itself. Otherwise the pattern may also match at any level below the .gitignore level.
If there is a separator at the end of the pattern then the pattern will only match directories, otherwise the pattern can match both files and directories.
For example, a pattern doc/frotz/ matches doc/frotz directory, but not a/doc/frotz directory; however frotz/ matches frotz and a/frotz that is a directory (all paths are relative from the .gitignore file).
An asterisk " * " matches anything except a slash. The character " ? " matches any one character except " / ". The range notation, e.g. [a-zA-Z], can be used to match one of the characters in a range.
Two consecutive asterisks (" ** ") in patterns matched against full pathname may have special meaning:
A leading " ** " followed by a slash means match in all directories. For example, " **/foo " matches file or directory "foo" anywhere, the same as pattern "foo". "**/foo/bar" matches file or directory "bar" anywhere that is directly under directory "foo".
A trailing " /** " matches everything inside. For example, " abc/** " matches all files inside directory "abc", relative to the location of the .gitignore file, with infinite depth.
A slash followed by two consecutive asterisks then a slash matches zero or more directories. For example, "a/**/b" matches "a/b", "a/x/b", "a/x/y/b" and so on.
Other consecutive asterisks are considered regular asterisks and will match according to the previous rules.
参考:
Pro Git, 2nd Edition(2014), Scott Chacon
https://git-scm.com/docs/gitignore
