├── .gitignore ├── Git ├── images │ ├── 11-1.png │ ├── 13-1.png │ ├── 22-1.png │ ├── 6-1.png │ ├── 6-2.png │ ├── 6-3.png │ ├── 8-1.png │ ├── 3-1终端.png │ ├── 19-1有序无环图.png │ ├── 3-1_IDE_VSCode.png │ ├── 3-2sourcetree.png │ ├── 4-git-insall-1.png │ ├── 4-git-insall-2.png │ ├── 4-git-insall-3.png │ ├── 4-git-insall-4.png │ ├── 4-git-insall-5.png │ ├── 4-git-insall-6.png │ ├── 4-git-insall-7.png │ ├── 4-git-insall-8.png │ ├── 4-git-insall-9.png │ ├── 1-1集中式、分散式、分布式示意图.png │ ├── 4-git-insall-10.png │ ├── 4-git-insall-11.png │ ├── 4-git-insall-12.png │ ├── 4-git-insall-13.png │ ├── 4-git-insall-14.png │ └── 4-git-insall-15.png ├── 03.使用Git的方式.md ├── 36.常见问题.md ├── 12.撤销修改-本地已保存状态.md ├── 29.合并已经拉取的更改.md ├── 33.推送变更.md ├── 26.合并到主分支.md ├── 30.拉取并合并.md ├── 34.拉取共享变更.md ├── 24.变基和合并.md ├── 09.设置别名.md ├── 32.裸仓库.md ├── 22.合并冲突.md ├── 25.使用变基合并分支.md ├── 07.更新文件并提交.md ├── 21.合并分支.md ├── 23.撤销合并（未完善）.md ├── 15.从分支中删除提交.md ├── 18.忽略文件.md ├── 01.初识Git.md ├── 10.切换版本.md ├── 02.Git的特性.md ├── 14.还原修改-已提交状态下.md ├── 16.修改提交内容.md ├── 31.创建一个跟踪分支.md ├── 35.托管Git仓库.md ├── 20.创建分支.md ├── 28.从原始仓库获取更改.md ├── 05.初始配置.md ├── 13.撤销修改-已暂存状态下.md ├── 08.查看提交历史.md ├── 06.创建本地仓库.md ├── 11.标签操作.md ├── 27.多存储库.md ├── 19.了解Git对象存储机制.md ├── 17.移动文件.md └── 04.安装Git.md ├── GItHub ├── images │ ├── image-20230610051658445.png │ ├── image-20230610052238373.png │ └── image-20230610052628825.png └── 如何向他人的项目提交内容.md ├── gitlab └── GitLab Install.md ├── README.md ├── SUMMARY.md └── summary.ps1 /.gitignore: -------------------------------------------------------------------------------- 1 | Thumbs.db 2 | -------------------------------------------------------------------------------- /Git/images/11-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/11-1.png -------------------------------------------------------------------------------- /Git/images/13-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/13-1.png -------------------------------------------------------------------------------- /Git/images/22-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/22-1.png -------------------------------------------------------------------------------- /Git/images/6-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/6-1.png -------------------------------------------------------------------------------- /Git/images/6-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/6-2.png -------------------------------------------------------------------------------- /Git/images/6-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/6-3.png -------------------------------------------------------------------------------- /Git/images/8-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/8-1.png -------------------------------------------------------------------------------- /Git/images/3-1终端.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/3-1终端.png -------------------------------------------------------------------------------- /Git/images/19-1有序无环图.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/19-1有序无环图.png -------------------------------------------------------------------------------- /Git/images/3-1_IDE_VSCode.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/3-1_IDE_VSCode.png -------------------------------------------------------------------------------- /Git/images/3-2sourcetree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/3-2sourcetree.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-1.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-2.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-3.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-4.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-5.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-6.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-7.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-8.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-9.png -------------------------------------------------------------------------------- /Git/images/1-1集中式、分散式、分布式示意图.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/1-1集中式、分散式、分布式示意图.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-10.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-11.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-12.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-13.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-14.png -------------------------------------------------------------------------------- /Git/images/4-git-insall-15.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/Git/images/4-git-insall-15.png -------------------------------------------------------------------------------- /GItHub/images/image-20230610051658445.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/GItHub/images/image-20230610051658445.png -------------------------------------------------------------------------------- /GItHub/images/image-20230610052238373.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/GItHub/images/image-20230610052238373.png -------------------------------------------------------------------------------- /GItHub/images/image-20230610052628825.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/apnpc/git-learnnig/HEAD/GItHub/images/image-20230610052628825.png -------------------------------------------------------------------------------- /Git/03.使用Git的方式.md: -------------------------------------------------------------------------------- 1 | # 03.使用 Git 的方式 2 | 3 | 使用 Git 的方式有三种，分别是命令行、图形化软件以及IDE集成环境。 4 | 5 | ## 命令行 6 | 7 | 使用 git 命令与 Git 交互 8 | 9 | ![3-1终端.png](./images/3-1终端.png) 10 | 11 | ## 图形化软件 12 | 13 | 使用图形化软件与 Git 交互，例如 [Sourcetree](https://www.sourcetreeapp.com/) 14 | 15 | ![3-2sourcetree.png](./images/3-2sourcetree.png) 16 | 17 | 还有很多图形化软件，请查看 18 | 19 | ## IDE 20 | 21 | ![3-1_IDE_VSCode.png](./images/3-1_IDE_VSCode.png) 22 | 23 | ## 另外推荐安装两个软件 24 | 25 | 1. WIndows Terminal，在微软应用商店就可以下载。 26 | 2. [VScode](https://code.visualstudio.com/) 27 | -------------------------------------------------------------------------------- /Git/36.常见问题.md: -------------------------------------------------------------------------------- 1 | # 36.常见问题 2 | 3 | ## Git 和 git 4 | 5 | Git 是指整个版本控制系统，以及它背后的概念和设计思想，而小写的git 代表使用 Git 功能所需要的命令，是用来与 Git 交互的。 6 | 7 | ## Git、GitHub、GitLab 8 | 9 | Git 是分布式工具，不依赖于任何中央仓库。但实际上，我们很依赖 GitHub 或 GitLab 这样的外部仓库。这是为什么？ 10 | 11 | GitHub 和 GitLab 都是一个基于 Git 的代码托管平台。它们的存在大大简化了开发团队成员之间的数据交换，并提供了额外的备份和各种其他功能。例如文档管理、错误跟踪、协作工具等。平台还提供了大量的开源项目，包括各种语言和框架的开源软件、工具和应用程序。开发者可以通过 GitHub 和 GitLab 学习其他人的项目，并参与到开源社区中来，从而不断提升自己的技术水平和经验。这也是开源软件开发中的一种重要的合作和分享方式。GitHub 和 GitLab 无处不在，为开发者提供了全球范围内的代码托管和协作平台。它们为开发者提供了非常方便的代码管理和协作工具，促进了开源软件和开发者社区的快速发展和创新。现代 Web 界面也更容易进行项目管理，可以让我们轻松进入和管理 Git 仓库。 12 | -------------------------------------------------------------------------------- /Git/12.撤销修改-本地已保存状态.md: -------------------------------------------------------------------------------- 1 | # 12.撤销修改-本地已保存状态 2 | 3 | 本节将学习如何恢复暂存前的更改，也就是在工作区下已经修改保存，还未暂存的文件。 4 | 5 | 每次操作前，我们都需要知道我们所在的分支，使用 `git status` 查看状态。目前我们还没有接触分支，你只需要知道你需要时刻关注这个状态。如果不在主分支上，使用 `git checkout master`切换到主分支。 6 | 7 | ## 修改文件 8 | 9 | 在 test 文件中添加一行 123，并保存。 10 | 11 | ```powershell 12 | # 查看文件内容 13 | $ cat .\test.txt 14 | abc 15 | 123 16 | ``` 17 | 18 | ## 恢复本地修改 19 | 20 | 现在我们尝试恢复操作，未暂存的文件恢复命令使用的是 `checkout` 命令，使用 `git checkout test.txt` 既可完成操作 21 | 22 | ```powershell 23 | # 恢复 24 | $ git checkout test.txt 25 | Updated 1 path from the index 26 | 27 | $ cat .\test.txt 28 | abc 29 | ``` 30 | -------------------------------------------------------------------------------- /Git/29.合并已经拉取的更改.md: -------------------------------------------------------------------------------- 1 | # 29.合并已经拉取的更改 2 | 3 | ## 实验 4 | 5 | 将原始仓库的更改合并到本地分支 6 | 7 | ```powershell 8 | # 将远程分支合并到本地分支 9 | $ git merge origin/master 10 | Updating 2456c71..b4e913c 11 | Fast-forward 12 | README.md | 1 + 13 | 1 file changed, 1 insertion(+) 14 | create mode 100644 README.md 15 | 16 | # 查看文件 17 | $ ls 18 | Directory: C:\Users\aku\Desktop\cloned_git_learnnig 19 | 20 | Mode LastWriteTime Length Name 21 | ---- ------------- ------ ---- 22 | d---- 2023/5/5 23:50 lab 23 | -a--- 2023/5/5 23:50 27 .gitignore 24 | -a--- 2023/5/6 1:18 13 README.md 25 | ``` 26 | 27 | 我们可以看到文件已经同步了。 28 | -------------------------------------------------------------------------------- /Git/33.推送变更.md: -------------------------------------------------------------------------------- 1 | # 33.推送变更 2 | 3 | 我们在原始仓库中编辑 README.md 并提交到裸仓库中。 4 | 5 | ```md 6 | 这条记录是在原始仓库中添加的 7 | ``` 8 | 9 | 执行命令： 10 | 11 | ```powershell 12 | # 暂存 13 | $ git add .\README.md 14 | 15 | # 提交 16 | $ git commit -m "Added shared comment to readme" 17 | [master 61e87c9] Added shared comment to readme 18 | 1 file changed, 3 insertions(+), 1 deletion(-) 19 | 20 | # 推送 21 | $ git push shared master 22 | 23 | Enumerating objects: 5, done. 24 | Counting objects: 100% (5/5), done. 25 | Delta compression using up to 4 threads 26 | Compressing objects: 100% (3/3), done. 27 | Writing objects: 100% (3/3), 371 bytes | 92.00 KiB/s, done. 28 | Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 29 | To ..\git_learning_git\ 30 | b4e913c..61e87c9 master -> master 31 | ``` 32 | -------------------------------------------------------------------------------- /Git/26.合并到主分支.md: -------------------------------------------------------------------------------- 1 | # 26.合并到主分支 2 | 3 | ```powershell 4 | git checkout master 5 | Switched to branch 'master' 6 | 7 | git merge lgnew 8 | Updating 1c78eab..2456c71 9 | Fast-forward 10 | lab/test2.txt | 0 11 | 1 file changed, 0 insertions(+), 0 deletions(-) 12 | create mode 100644 lab/test2.txt 13 | 14 | git hist 15 | * 2456c71 2023-05-05 | Added teset2.txt (HEAD -> master, lgnew) [aku] 16 | * 1c78eab 2023-05-05 | Added teset3.txt [aku] 17 | * 31e5621 2023-05-05 | Added teset2.txt [aku] 18 | * 5dc8b1e 2023-05-05 | Added .gitignore [aku] 19 | * b77158a 2023-05-05 | Moved test.txt to lab [aku] 20 | * 929f644 2023-05-05 | Added 123456 to the test.txt [aku] 21 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 22 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 23 | ``` 24 | 25 | 从日志的输出结果来看，对于本地代码迭代，我们最好在新分支上操作，这样可以降低影响主分支，并且保持主分支的提交干净整洁。 26 | -------------------------------------------------------------------------------- /Git/30.拉取并合并.md: -------------------------------------------------------------------------------- 1 | # 30.拉取并合并 2 | 3 | `git pull` 可以一步实现 `git fetch`（拉取） 和`git merge`（合并） 的功能。 4 | 5 | `git fetch` 命令会获取远程存储库中的所有代码更改，并将它们存储在名为 "remote branches" 的本地分支中。这些本地分支反映了远程存储库中存在的每个分支和其相应的提交历史记录。由于 `fetch` 不会自动将代码更改合并到当前活动分支中，因此您必须手动将其合并，例如使用 `git merge` 命令。 6 | > remote branches 在本地看来是远程分支信息，实际上本地已经存储了 7 | 8 | `git pull` 命令则会自动获取远程存储库的代码更改，并将其合并到当前活动分支中。具体来说，`pull` 命令首先运行 `git fetch`，然后自动将远程存储库的代码更改合并到当前活动分支中。 9 | 10 | `git merge` 命令是一个用于手动合并两个分支的命令。通常，它用于将本地存储库中的更改合并到远程存储库中或将一个分支中的更改合并到另一个分支中。它需要两个参数，即要合并到当前分支的目标分支和要合并的源分支。 11 | 12 | 以下是这些命令之间关系的总结： 13 | 14 | - `git fetch`: 获取远程存储库中的最新代码更改，并将其保存在本地存储库中的 "remote branches" 中。 15 | - `git pull`: 运行 `git fetch` 命令以获取远程存储库中的最新代码更改，然后自动将其合并到当前活动分支中。 16 | - `git merge`: 手动将两个分支合并，并创建一个新的合并提交记录。 17 | 18 | 需要注意的是，尽管 `pull` 命令可以更快地获取远程存储库的最新代码更改并将其合并到本地存储库中，但它也可能会导致合并冲突。因此，在运行 `pull` 命令之前，请确保所有本地更改都已提交或保存。 19 | -------------------------------------------------------------------------------- /Git/34.拉取共享变更.md: -------------------------------------------------------------------------------- 1 | # 34.拉取共享变更 2 | 3 | 进入克隆库 `cloned_git_learnnig`操作 4 | 5 | ```powershell 6 | # 添加远程仓库 7 | $ git remote add shared ..\git_learning_git\ 8 | 9 | # 创建跟踪分支 10 | $ git branch --track shared master 11 | branch 'shared' set up to track 'master'. 12 | 13 | # 拉取共享库 14 | $ git pull shared master 15 | 16 | remote: Enumerating objects: 5, done. 17 | remote: Counting objects: 100% (5/5), done. 18 | remote: Compressing objects: 100% (3/3), done. 19 | remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 20 | Unpacking objects: 100% (3/3), 351 bytes | 25.00 KiB/s, done. 21 | From ..\git_learning_git\ 22 | * branch master -> FETCH_HEAD 23 | * [new branch] master -> shared/master 24 | Updating b4e913c..61e87c9 25 | Fast-forward 26 | README.md | 4 +++- 27 | 1 file changed, 3 insertions(+), 1 deletion(-) 28 | 29 | # 查看文件 30 | $ cat .\README.md 31 | Git Learnning 32 | 这条记录是在原始仓库中添加的 33 | 34 | ``` 35 | -------------------------------------------------------------------------------- /Git/24.变基和合并.md: -------------------------------------------------------------------------------- 1 | # 24.变基和合并 2 | 3 | `Rebasing`（变基） 和 `Merging`（合并） 是 Git 中常用的两种集成分支的方法。这两种方法都可以将一个分支的更改合并到另一个分支中，但它们的内部实现不同，因此其使用场景和结果也略有不同。 4 | 5 | > rebase _v._ 重定（税收、价格指数等）的基准，变基的意思大概是改变基础吧。这个词念起来来别扭的很。 6 | 7 | ## Rebasing 8 | 9 | `Rebasing` 是一种将分支更改应用于目标分支的方法，它会将分支的每个提交都转移到目标分支的顶部，并在每个提交之间将目标分支的更改应用于分支更改。这意味着，当你使用 `Rebasing` 方法时，最终的提交历史记录是一个线性的历史记录，其中所有更改都按照时间顺序排列。 10 | 11 | 主要优点： 12 | 13 | - 提交历史记录更加干净和有序。 14 | - 可以快速解决由于分支变化而导致的代码冲突。 15 | 16 | 主要缺点： 17 | 18 | - 可能需要耗费大量时间和精力来处理冲突。 19 | - 对于多人协作开发而言，可能需要进行协调才能确保不出现问题。 20 | 21 | ## Merging 22 | 23 | `Merging` 是一种将分支更改合并到目标分支的方法。它会创建一个新的合并提交，该提交包含了目标分支和要合并的分支的全部更改。这意味着，当你使用 `Merging` 方法时，最终的提交历史记录将包含合并提交以及两个分支的更改历史记录。 24 | 25 | 主要优点： 26 | 27 | - 容易理解和使用。 28 | - 不需要手动处理冲突。 29 | 30 | 主要缺点： 31 | 32 | - 提交历史记录可能会变得杂乱无序，难以阅读和理解。 33 | - 如果分支更改频繁，可能会导致大量的冲突。 34 | 35 | 综上所述，`Rebasing` 和 `Merging` 都是有效的集成分支的方法，它们适用于不同的场景。如果你需要保持提交历史记录的整洁和有序，或者需要快速解决由于分支变化而导致的代码冲突，则可以选择使用 `Rebasing` 方法。如果你需要简单地将一个分支的更改合并到另一个分支中，并且不关心最终的提交历史记录，则可以选择使用 `Merging` 方法。 36 | -------------------------------------------------------------------------------- /gitlab/GitLab Install.md: -------------------------------------------------------------------------------- 1 | # GitLab 2 | 3 | ## GitLab Install 4 | 5 | https://about.gitlab.com/install/ 6 | 7 | ```shell 8 | sudo dnf install -y curl policycoreutils openssh-server perl 9 | 10 | # Enable OpenSSH server daemon if not enabled: sudo systemctl status sshd 11 | sudo systemctl enable sshd 12 | sudo systemctl start sshd 13 | 14 | # Check if opening the firewall is needed with: sudo systemctl status firewalld 15 | sudo firewall-cmd --permanent --add-service=http 16 | sudo firewall-cmd --permanent --add-service=https 17 | sudo systemctl reload firewalld 18 | sudo dnf install postfix 19 | sudo systemctl enable postfix 20 | sudo systemctl start postfix 21 | 22 | curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash 23 | 24 | sudo EXTERNAL_URL="https://gitlab.example.com" dnf install -y gitlab-ee 25 | # List available versions: sudo dnf --showduplicates list 26 | # Specify version: sudo dnf install gitlab-ee-16.1.4-ee.0.el7 27 | 28 | EXTERNAL_URL="http://10.10.1.150" dnf install -y gitlab-ee 29 | grep 'Password:' /etc/gitlab/initial_root_password 30 | ``` -------------------------------------------------------------------------------- /Git/09.设置别名.md: -------------------------------------------------------------------------------- 1 | # 09.设置别名 2 | 3 | 顾名思义，别名就是另外一个名字，大名不好叫，取一个狗蛋的名字，好记又好叫。Git 支持命令别名，你可以通过修改配置文件或者使用命令的方式告诉 Git 你要使用别名的命令。 4 | 5 | 下面的命令是上一节的格式化提交的命令，我们现在可以将命令缩短为 `git hist`。就可以得到我们想要的效果。 6 | 7 | ```powershell 8 | git log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short 9 | ``` 10 | 11 | ## 通过配置文件设定别名 12 | 13 | 首先，打开终端，在终端中输入 `git config --show-origin` 查看配置文件目录，我们修改用户配置文件 gitconfig。在配置文件中添加 alias ，将别名和替代的命令写入其中并保存。 14 | 15 | ```conf 16 | [user] 17 |     name = aku 18 |     email = aku@example.com 19 | [core] 20 |     editor = code --wait 21 | [alias] 22 |     hist = "log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short" 23 |     ci = commit 24 |     st = status 25 | ``` 26 | 27 | 然后你就可以使用 `git hist` 来格式化输出了。 28 | 29 | ```powershell 30 | $ git hist 31 | * d7f681f 2023-05-05 | Added abc to the test.txt (HEAD -> master) [aku] 32 | * 01b8702 2023-05-05 | Add first file [aku] 33 | ``` 34 | 35 | 同理，我们也可以将 `commit` 设置成 `ci`。 36 | 37 | ## 通过命令设定 38 | 39 | 另外一种方式是通过 `git config`命令来实现。比如我们要将 status 命令设置为 st，可以使用如下命令。 40 | 41 | ```powershell 42 | git config --global alias.st 'status' 43 | ``` 44 | -------------------------------------------------------------------------------- /GItHub/如何向他人的项目提交内容.md: -------------------------------------------------------------------------------- 1 | # 如何向他人的项目提交内容？ 2 | 3 | ```mermaid 4 | graph TB 5 | A[开始] --> B[Fork- 复制该仓库] 6 | B --> C[克隆已经复制的仓库] 7 | C --> D[创建一个新分支] 8 | D --> E[编写内容] 9 | E --> F[推送修改到分支] 10 | F --> G{测试} 11 | G -->|Yes| H[创建PR-创建推送请求] 12 | G -->|No| I[修复内容] 13 | I --> F 14 | H --> J{PR 批准?} 15 | J -->|Yes| K[合并PR] 16 | J -->|No| L[处理审查意见] 17 | L --> F 18 | K --> M[删除分支] 19 | M --> N[结束] 20 | 21 | ``` 22 | 23 | ## 第一步 Fxxk 它 24 | 25 | 1. 进入你想参与的项目，点击右上角的 Fork 26 | 27 | ![image-20230610051658445](./images/image-20230610051658445.png) 28 | 29 | 2. 之后会引导你创建一个属于你个人的一个仓库。 30 | 3. 创建完成之后，你可以在自己的仓库目录下看到你想参与的项目。 31 | 32 | ![image-20230610052238373](./images/image-20230610052238373.png) 33 | 34 | 35 | 36 | ## 第二步 修改内容 37 | 38 | 接下来你可以将项目克隆到本地进行编辑修改，然后提交。这些内容在 Git 基础学习中已经阐述了，可以参考页头的流程图进行相应操作。 39 | 40 | ## 第三步 推送请求 41 | 42 | > **Note** 43 | > 44 | > 推送前一定要多次验证 45 | 46 | 推送请求有两个方式： 47 | 48 | 1.再回到你 Fork 仓库项目目录，点击 `commit ahead`，会跳转到源项目，点击创建一个PR（create pull request），填写提交说明并提交，之后就是等待项目管理人员审核你的提交，审核通过或者不通过都会给你发消息。 49 | 50 | ![image-20230610052628825](./images/image-20230610052628825.png) 51 | 52 | 2. 直接进入源仓库目录，点击目录上方的 `Pull requests`，按照引导完成提交。 53 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # git-learnnig 2 | 3 | ## 目的 4 | 5 | 本课程旨在为初学者提供一个全面而简洁的介绍，让你快速掌握 Git 的基本概念和使用方法。无论你是一名软件开发新手、项目经理还是对版本控制感兴趣的任何人，本课程都将为你建立起坚实的Git基础。 6 | 7 | 主打的就是一个简单，每个小节都涉及到 Git 的核心知识，并有相关的实验，相信你在阅读完后会对 Git 有一个比较全面的认识。 8 | 9 | ## 注意事项 10 | 11 | 1. 本教程基于 Windows 10 操作系统，Git 版本 version 2.40.1.windows.1 12 | 2. 必须动手，请按照实验内容自己敲一遍； 13 | 3. 请配合 Git 官方书籍 [《Git pro》](https://git-scm.com/book/zh/v2)查缺补漏； 14 | 4. 命令展示说明。 15 | 16 | ```PowerShell 17 | # 这条是注释 18 | $ 这条是命令 19 | 这条是命令的输出内容 20 | ``` 21 | 22 | ## 图谱 23 | 24 | ```mermaid 25 | graph TD 26 | A[仓库] --> B[提交] 27 | A --> C[分支] 28 | A --> D[远程管理] 29 | C --> E[主分支] 30 | C --> F[开发分支] 31 | C --> G[功能分支] 32 | C --> H[发布分支] 33 | C --> I[热修复分支] 34 | B --> J[哈希值] 35 | B --> K[日志信息] 36 | B --> L[作者和时间] 37 | C --> M[合并] 38 | D --> N[克隆] 39 | D --> O[推送] 40 | D --> P[拉取] 41 | E --> Q[版本回退] 42 | F --> Q 43 | G --> Q 44 | H --> Q 45 | I --> Q 46 | M --> R[解决代码冲突] 47 | M --> S[处理自动合并和手动合并] 48 | T[工作流程] --> U[Git Flow] 49 | T --> V[GitHub Flow] 50 | T --> W[Trunk Based Development] 51 | X[命令行界面] --> A 52 | Y[图形用户界面] --> A 53 | Z[IDE 集成] --> A 54 | 1[仓库] --> 2[工作区] 55 | 1[仓库] --> 3[暂存区] 56 | 1[仓库] --> 4[版本库] 57 | 58 | 59 | ``` 60 | -------------------------------------------------------------------------------- /Git/32.裸仓库.md: -------------------------------------------------------------------------------- 1 | # 32.裸仓库 2 | 3 | 裸仓库（bare repository）是一个没有工作目录的 Git 存储库。通常来说，Git 存储库会包含一个 ".git" 目录和一个工作目录，该目录中保存了项目文件的副本以及对它们进行的修改。而裸仓库则只包含 ".git" 目录，其中存储着版本控制所需要的所有文件，包括对象数据库、索引和配置文件，但不包含实际的项目文件。 4 | 5 | 因为裸仓库没有工作目录，所以不能像普通的 Git 存储库一样进行日常开发工作。相反，裸仓库主要用于共享代码库或作为远程存储库使用。例如，软件开发团队可能会在内部网络上设置一个裸仓库，允许成员共享代码而无需每次都将代码复制到各自的计算机上。 6 | 7 | 与非裸仓库相比，裸仓库在协作开发和持续集成方面具有许多优势。由于裸仓库不包含工作目录，因此它们不会与其他分支或提交之间产生冲突，并且可以轻松地与其他远程存储库同步。此外，由于裸仓库不包含工作目录，因此它们的大小更小，可以更快地传输和克隆。 8 | 9 | ## 创建文件夹 10 | 11 | 创建文件夹 `git_learning_git` 12 | 13 | ```powershell 14 | # 查看文件列表 15 | $ ls 16 | 17 | Directory: C:\Users\aku\Desktop 18 | Mode LastWriteTime Length Name 19 | ---- ------------- ------ ---- 20 | d---- 2023/5/6 2:52 cloned_git_learnnig 21 | d---- 2023/5/6 11:54 git_learning 22 | d---- 2023/5/6 2:47 git_learning_git 23 | ``` 24 | 25 | ## 创建裸仓库 26 | 27 | ```powershell 28 | # --bare 用于创建一个裸仓库 29 | $ git clone --bare .\git_learning\ .\git_learning_git\ 30 | Cloning into bare repository '.\git_learning_git'... 31 | done. 32 | ``` 33 | 34 | ## 将裸仓库添加为我们原始仓库的远程仓库 35 | 36 | 在原始仓库 `git_learning_git` 中执行 37 | 38 | ```powershell 39 | cd .\git_learning\ 40 | git remote add shared ..\git_learning_git\ 41 | ``` 42 | -------------------------------------------------------------------------------- /Git/22.合并冲突.md: -------------------------------------------------------------------------------- 1 | # 22.合并冲突 2 | 3 | 在 Git 中，当尝试将两个不同的分支合并时，可能会出现合并冲突。这通常发生在两个分支上都更改了同一文件的同一部分时。 4 | 5 | ## 实验 6 | 7 | ### 制造冲突 8 | 9 | ```powershell 10 | # 切换到新分支 11 | git checkout lgnew 12 | 13 | # 编辑test文件，添加一行内容 123,并提交 14 | cat .\lab\test.txt 15 | abc 16 | 123 17 | git commit -a -m "added 123 to the test.txt" 18 | 19 | # 切换回主分支 20 | git checkout master 21 | 22 | # 编辑test文件，添加一行内容 456,并提交 23 | # 编辑test文件，添加一行内容 123,并提交 24 | cat .\lab\test.txt 25 | abc 26 | 456 27 | git commit -a -m "added 456 to the test.txt" 28 | 29 | # 合并 30 | git merge lgnew 31 | Auto-merging lab/test.txt 32 | CONFLICT (content): Merge conflict in lab/test.txt 33 | Automatic merge failed; fix conflicts and then commit the result. 34 | ``` 35 | 36 | ### 合并冲突 37 | 38 | 合并冲突需要手动解决，因为我之前设置了 VScode 为默认编辑器，当冲突出现的时候会自动调用。 39 | ![[22-1.png]] 40 | 41 | VScode 把冲突内容非常直观的列举出来了， 现在我们只需更改 Result 部分，并点击 Complete Merge （解决冲突）。然后还需要再次提交，才算完成合并。 42 | 43 | ```powershell 44 | $ git commit -m "Resolved merge conflict" 45 | 46 | $ git hist 47 | * 64e4a16 2023-05-05 | Resolved merge conflict (HEAD -> master) [aku] 48 | |\ 49 | | * 25f40b0 2023-05-05 | added 123 to the test.txt (lgnew) [aku] 50 | * | ea38cf4 2023-05-05 | added 456 to the test.txt [aku] 51 | * | edee6c9 2023-05-05 | Revert "Merge branch 'lgnew'" [aku] 52 | * | 22c6905 2023-05-05 | Merge branch 'lgnew' [aku] 53 | ``` 54 | -------------------------------------------------------------------------------- /Git/25.使用变基合并分支.md: -------------------------------------------------------------------------------- 1 | # 25.使用变基合并分支 2 | 3 | ## 将分支恢复到合并之前 4 | 5 | ```powershell 6 | git checkout lgnew 7 | 8 | git hist 9 | * 1ef2ec3 2023-05-05 | Merge branch 'master' into lgnew (HEAD -> lgnew) [aku] 10 | |\ 11 | | * 1c78eab 2023-05-05 | Added teset3.txt (master) [aku] 12 | * | 3d99c8f 2023-05-05 | Added teset2.txt [aku] 13 | |/ 14 | * 31e5621 2023-05-05 | Added teset2.txt [aku] 15 | * 5dc8b1e 2023-05-05 | Added .gitignore [aku] 16 | * b77158a 2023-05-05 | Moved test.txt to lab [aku] 17 | * 929f644 2023-05-05 | Added 123456 to the test.txt [aku] 18 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 19 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 20 | 21 | # 重置到合并前的最后一次提交 22 | $ git reset --hard 3d99c8f 23 | HEAD is now at a3f191c Added test3.txt 24 | ``` 25 | 26 | ## 变基 27 | 28 | ```powershell 29 | git rebase master 30 | Successfully rebased and updated refs/heads/master. 31 | 32 | git hist 33 | * 2456c71 2023-05-05 | Added teset2.txt (HEAD -> lgnew) [aku] 34 | * 31e5621 2023-05-05 | Added teset2.txt [aku] 35 | * 5dc8b1e 2023-05-05 | Added .gitignore [aku] 36 | * b77158a 2023-05-05 | Moved test.txt to lab [aku] 37 | * 929f644 2023-05-05 | Added 123456 to the test.txt [aku] 38 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 39 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 40 | ``` 41 | 42 | ## 什么时候用变基 43 | 44 | 不用最好 45 | -------------------------------------------------------------------------------- /Git/07.更新文件并提交.md: -------------------------------------------------------------------------------- 1 | # 07.更新文件并提交 2 | 3 | ## 实验 4 | 5 | 在 test.txt 文件中添加一行内容 abc，提交至版本库 6 | 7 | ```powershell 8 | # 查看仓库状态 9 | $ git status 10 | On branch master 11 | Changes not staged for commit: 12 | (use "git add ..." to update what will be committed) 13 | (use "git restore ..." to discard changes in working directory) 14 | modified: test.txt 15 | # 暂存文件 16 | $ git add test.txt 17 | 18 | # 提交更改 19 | $ git commit -m "Added abc to the test.txt" 20 | [master d7f681f] Added abc to the test.txt 21 | 1 file changed, 1 insertion(+) 22 | ``` 23 | 24 | ## `git add`重复操作？ 25 | 26 | > test.txt 文件已经被追踪了，为什么修改之后还需要使用`git add`重复操作？ 27 | 28 | 在上一节中，我们已经使用 `git add` 命令告诉 Git 追踪 test 文件，并使用 `git commit` 保存到了版本库。按照常理，文件已经被系统接管，文件的状态会被识别，大可不必再次重复操作。 29 | 30 | 但实际情况是，当我们对一个已经被 Git 追踪的文件进行更改时，我们需要再次使用 `git add` 命令。这是因为 Git 对更改的追踪是基于内容，而不仅仅是文件。这意味着，当文件的内容发生更改时，Git 视这些更改为新的内容，并需要你明确地将这些新的更改添加到暂存区。 31 | 32 | ## 跳过使用暂存区域 33 | 34 | 每次都需要执行暂存命令，有点繁琐，如果你希望跳过暂存区，直接将更改提交到版本库中，则可以使用以下命令： 35 | 36 | ```bash 37 | git commit -a -m "Commit message" 38 | ``` 39 | 40 | 在这个命令中，`-a` 选项参数表示自动将所有已修改的文件添加到暂存区中，并将其提交到版本控制系统中。这样就可以跳过将更改显式添加到暂存区的步骤，直接将所有更改一次性提交。 41 | 42 | 需要注意的是，在使用该命令时，只会将已修改的文件提交到版本控制系统中，而对于新添加的文件则不会生效。如果您要将新添加的文件也提交到版本控制系统中，则需要手动将其添加到暂存区（使用 `git add` 命令）或者使用 `-a` 选项参数的组合命令 `git commit -am "Commit message"`，它相当于执行了 `git add .` 和 `git commit` 两个命令。 43 | 44 | 尽管跳过暂存区可能会使提交更加方便快捷，但建议在进行提交前仔细检查所做的更改并确保代码能够正常运行。 这样可以避免不必要的错误和引入不良代码。 45 | -------------------------------------------------------------------------------- /Git/21.合并分支.md: -------------------------------------------------------------------------------- 1 | # 21.合并分支 2 | 3 | 在 Git 中，合并分支是一种将两个不同的分支中的代码更改合并到一个分支中的操作。这允许团队成员在不同的分支中开发功能和修复错误，并最终将它们合并到主分支或其他稳定分支中。 4 | 5 | 以下是一些常见的 Git 合并命令： 6 | 7 | - `git merge `: 将指定的分支合并到当前分支。 8 | - `git merge --abort`: 取消正在进行的合并操作。 9 | - `git merge --no-ff `: 强制使用新的提交记录来创建合并提交，而不是采用快进模式（Fast-forward），从而保留分支历史记录。 10 | 11 | ## 将 master 合并至 lgnew 12 | 13 | ```powershell 14 | # 切换分支 15 | $ git checkout lgnew 16 | 17 | # 合并 18 | $ git merge master 19 | Merge made by the 'ort' strategy. 20 | lab/test3.txt | 0 21 | 1 file changed, 0 insertions(+), 0 deletions(-) 22 | create mode 100644 lab/test3.txt 23 | ``` 24 | 25 | 将 `lgnew` 分支中的所有更改合并到 `master` 分支中，并创建一个新的合并提交记录。 26 | 27 | ```powershell 28 | # 查看提交日志 29 | $ git hist --all 30 | 31 | * 1ef2ec3 2023-05-05 | Merge branch 'master' into lgnew (HEAD -> lgnew) [aku] 32 | |\ 33 | | * 1c78eab 2023-05-05 | Added teset3.txt (master) [aku] 34 | * | 3d99c8f 2023-05-05 | Added teset2.txt [aku] 35 | |/ 36 | * 5dc8b1e 2023-05-05 | Added .gitignore [aku] 37 | * b77158a 2023-05-05 | Moved test.txt to lab [aku] 38 | * 929f644 2023-05-05 | Added 123456 to the test.txt [aku] 39 | | * 739560c 2023-05-05 | Oops,an error committed (tag: oops) [aku] 40 | | * 1ca1854 2023-05-05 | Revert "Added 123 to the test.txt" [aku] 41 | | * 375f4fe 2023-05-05 | Added 123 to the test.txt [aku] 42 | |/ 43 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 44 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 45 | ``` 46 | -------------------------------------------------------------------------------- /Git/23.撤销合并（未完善）.md: -------------------------------------------------------------------------------- 1 | # 23.撤销合并（未完善） 2 | 3 | 先跳过本节 4 | 5 | ## 恢复已提交的合并 6 | 7 | ### 使用 revert 8 | 9 | 此方法会创建新的 commit 来抵消对应的 merge 操作。再次合并时，文件无法合并，会提示 Already up-to-date. Git 误以为撤销的分支，所有内容我们都不需要了。 10 | 11 | 我们上个实验，将 lgnew 分支合并到了 master ，为了演示冲突，我们需要撤销合并。合并操作分为两步。 12 | 13 | 1. 找到合并的哈希值。使用 git hist 查看； 14 | 2. 确定撤销合并提交中的父提交编号 15 | 3. 使用 `git revert` 命令撤销合并。 16 | 17 | ```powershell 18 | # 找到合并分支的提交哈希值 19 | git hist --all 20 | * 8588c0b 2023-05-05 | Merge branch 'lgnew' [aku] 21 | |\ 22 | | * ead2515 2023-05-05 | Added teset2.txt (HEAD -> lgnew) [aku] 23 | * | da0a6f8 2023-05-05 | Added teset3.txt [aku] 24 | |/ 25 | 26 | # 查看提交详细信息 27 | commit 8588c0b75af1f1a1cb29cb95d874631a39d30ef8 28 | Merge: da0a6f8 ead2515 29 | Author: aku 30 | Date: Fri May 5 13:39:39 2023 -0700 31 | 32 | Merge branch 'lgnew' 33 | 34 | # 恢复 35 | git revert -m 1 8588c0b 36 | [master 32c5d64] Revert "Merge branch 'lgnew'" 37 | 1 file changed, 0 insertions(+), 0 deletions(-) 38 | delete mode 100644 lab/test2.txt 39 | ``` 40 | 41 | 使用 `git revert` 命令来撤销先前的合并提交时，需要指定要撤销的父提交。`-m` 选项用于指定要撤销的合并提交中的父提交编号。`1` 是 `-m` 选项后面的参数，表示要使用的父提交编号。 42 | 43 | 合并提交的哈希值是 `8588c0b`，这个合并提交包含了两个父提交 `Merge: da0a6f8 ead2515` 44 | 45 | - `ead2515 2023-05-05 | Added teset2.txt (HEAD -> lgnew) [aku]` 46 | - `da0a6f8 2023-05-05 | Added teset3.txt [aku]` 47 | 48 | 通过 `-m` 选项指定的父提交序号，可以告诉 Git 要撤销哪个父提交。使用 `-m 1` 表示要撤销的父提交是序号为 `1` 的父提交，即父提交 `da0a6f8`。 49 | 50 | --- 51 | 52 | 此方法会创建新的 commit 来抵消对应的 merge 操作。再次合并时，文件无法合并，会提示 Already up-to-date. Git 误以为这个分支的东西都是不想要的。 53 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | 2 | # Summary 3 | 4 | * [Git/](Git/) 5 | * [01.初识Git](Git/01.初识Git.md) 6 | * [02.Git的特性](Git/02.Git的特性.md) 7 | * [03.使用Git的方式](Git/03.使用Git的方式.md) 8 | * [04.安装Git](Git/04.安装Git.md) 9 | * [05.初始配置](Git/05.初始配置.md) 10 | * [06.创建本地仓库](Git/06.创建本地仓库.md) 11 | * [07.更新文件并提交](Git/07.更新文件并提交.md) 12 | * [08.查看提交历史](Git/08.查看提交历史.md) 13 | * [09.设置别名](Git/09.设置别名.md) 14 | * [10.切换版本](Git/10.切换版本.md) 15 | * [11.标签操作](Git/11.标签操作.md) 16 | * [12.撤销修改-本地已保存状态](Git/12.撤销修改-本地已保存状态.md) 17 | * [13.撤销修改-已暂存状态下](Git/13.撤销修改-已暂存状态下.md) 18 | * [14.还原修改-已提交状态下](Git/14.还原修改-已提交状态下.md) 19 | * [15.从分支中删除提交](Git/15.从分支中删除提交.md) 20 | * [16.修改提交内容](Git/16.修改提交内容.md) 21 | * [17.移动文件](Git/17.移动文件.md) 22 | * [18.忽略文件](Git/18.忽略文件.md) 23 | * [19.了解Git对象存储机制](Git/19.了解Git对象存储机制.md) 24 | * [20.创建分支](Git/20.创建分支.md) 25 | * [21.合并分支](Git/21.合并分支.md) 26 | * [22.合并冲突](Git/22.合并冲突.md) 27 | * [23.撤销合并（未完善）](Git/23.撤销合并（未完善）.md) 28 | * [24.变基和合并](Git/24.变基和合并.md) 29 | * [25.使用变基合并分支](Git/25.使用变基合并分支.md) 30 | * [26.合并到主分支](Git/26.合并到主分支.md) 31 | * [27.多存储库](Git/27.多存储库.md) 32 | * [28.从原始仓库获取更改](Git/28.从原始仓库获取更改.md) 33 | * [29.合并已经拉取的更改](Git/29.合并已经拉取的更改.md) 34 | * [30.拉取并合并](Git/30.拉取并合并.md) 35 | * [31.创建一个跟踪分支](Git/31.创建一个跟踪分支.md) 36 | * [32.裸仓库](Git/32.裸仓库.md) 37 | * [33.推送变更](Git/33.推送变更.md) 38 | * [34.拉取共享变更](Git/34.拉取共享变更.md) 39 | * [35.托管Git仓库](Git/35.托管Git仓库.md) 40 | * [36.常见问题](Git/36.常见问题.md) 41 | * [GItHub/](GItHub/) 42 | * [如何向他人的项目提交内容](GItHub/如何向他人的项目提交内容.md) 43 | * [README](README.md) 44 | -------------------------------------------------------------------------------- /Git/15.从分支中删除提交.md: -------------------------------------------------------------------------------- 1 | # 15.从分支中删除提交 2 | 3 | 本节我们学习如何删除提交。 4 | 5 | ## 创建一个新提交，并打上标签 6 | 7 | 在 test 文件中，添加一行 oops，并提交 8 | 9 | ```powershell 10 | # 查看文件内容 11 | $ cat .\test.txt 12 | abc 13 | oops 14 | 15 | # 提交到版本库 16 | $ git commit -a -m "Oops,an error committed" 17 | 18 | # 查看提交日志 19 | $ git hist 20 | * 739560c 2023-05-05 | Oops,an error committed (HEAD -> master) [aku] 21 | * 1ca1854 2023-05-05 | Revert "Added 123 to the test.txt" [aku] 22 | * 375f4fe 2023-05-05 | Added 123 to the test.txt [aku] 23 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 24 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 25 | 26 | # 打上标签 oops 27 | git tag oops 28 | 29 | $ cat .\test.txt 30 | abc 31 | oops 32 | ``` 33 | 34 | ## 恢复提交之前的文件 35 | 36 | ```powershell 37 | $ git reset --hard v1 38 | 39 | $ git hist 40 | * d7f681f 2023-05-05 | Added abc to the test.txt (HEAD -> master, tag: v1) [aku] 41 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 42 | 43 | $ cat .\test.txt 44 | abc 45 | ``` 46 | 47 | 之前我们说过 `HEAD` 是 Git 中一个特殊的指针，它始终指向当前所在分支的最新提交（或者是合并操作中的合并状态）。命令的意思是将您当前分支的 HEAD 指针重置到 v1 标签所指向的提交，同时强制更新工作目录和暂存区以与该提交匹配。这将删除所有未提交的更改和文件，并永久性地回滚您的代码库至 v1 标签所代表的状态。 48 | 49 | ## 记录其实还在，并且我们还可以引用 50 | 51 | ```powershell 52 | $ git hist --all 53 | * 2dd1257 2023-05-04 | Oops,an error committed (tag: oops) [aku] 54 | * bcd7c90 2023-05-04 | Added abc (HEAD -> master, tag: v1) [aku] 55 | * 05ade05 2023-05-04 | Add first file (tag: v1-beta) [aku] 56 | ``` 57 | 58 | 本地分支的重置通常是安全的。任何“意外”情况通常可以通过使用所需提交再次重置来恢复。但是，如果该分支在远程存储库上共享，则重置可能会使其他共享该分支的用户感到困惑。 59 | -------------------------------------------------------------------------------- /Git/18.忽略文件.md: -------------------------------------------------------------------------------- 1 | # 18.忽略文件 2 | 3 | 有一些文件我们并不需要让 Git 管理，比如临时文件、日志文件等。Git 为我们提供忽略文件的配置。 4 | 5 | ## 创建并提交 `.gitignore` 6 | 7 | 在仓库根目录创建一个 `.gitignore`，并将需要忽略的文件写入。`*` 是一个通配符，表示任意字符，`*.log` 表示以 `.log` 结尾的所有文件 8 | 9 | ```conf 10 | # 忽略日志文件 11 | *.log 12 | ``` 13 | 14 | 将 `.gitignore` 保存并提交 15 | 16 | ```powershell 17 | # 暂存 18 | git add .gitignore 19 | 20 | # 提交 21 | git commit -m "Added .gitignore" 22 | [master 4c40cbe] Added .gitignore 23 | 1 file changed, 2 insertions(+) 24 | create mode 100644 .gitignore 25 | 26 | # 查看日志 27 | git hist 28 | * 5dc8b1e 2023-05-05 | Added .gitignore (HEAD -> master) [aku] 29 | * b77158a 2023-05-05 | Moved test.txt to lab [aku] 30 | * 929f644 2023-05-05 | Added 123456 to the test.txt [aku] 31 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 32 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 33 | ``` 34 | 35 | ## 创建测试文件 36 | 37 | 我们在仓库根目录创建一个 git.log 文件，并查看 Git 状态 38 | 39 | ```powershell 40 | # 查看 Git 状态 41 | $ git status 42 | On branch master 43 | nothing to commit, working tree clean 44 | ``` 45 | 46 | 我们可以看到， 我新建的 git.log 文件并没有显示未追踪状态 47 | 48 | ## `.gitignore` 配置文件的一些例子 49 | 50 | ```conf 51 | # 忽略日志文件 52 | *.log 53 | 54 | # 上一个配置忽略所有log文件，但是 main.log除外 55 | !main.log 56 | 57 | # 只忽略当前目录下的 Log 文件，其它路径下不管 58 | /Log 59 | 60 | # 忽略任何目录下名为 build 的文件夹 61 | build/ 62 | 63 | # 忽略 doc/notes.txt，但不忽略 doc/server/arch.txt 64 | doc/*.txt 65 | 66 | # 忽略 doc/ 目录及其所有子目录下的 .pdf 文件 67 | doc/**/*.pdf 68 | ``` 69 | 70 | GitHub 有一个十分详细的针对数十种项目及语言的 `.gitignore` 文件列表， 你可以在 [https://github.com/github/gitignore](https://github.com/github/gitignore) 找到它。 71 | -------------------------------------------------------------------------------- /Git/01.初识Git.md: -------------------------------------------------------------------------------- 1 | # 01.初识 Git 2 | 3 | Git 最初由 Linus Torvalds 创建并开发，现在已成为全球范围内最受欢迎的版本控制工具之一，被广泛用于软件开发、文档编写、网站管理等各种领域。 4 | 5 | 翻译成人话就是，Git 是现在最受欢迎的分布式版本控制系统，可以说是行业标准，用于跟踪管理代码或者文档，并且它是免费、开源的。 6 | 7 | ## 分布式 8 | 9 | 分布式是一种计算机系统的设计方法，它将计算机系统中的不同部分分散在不同的地方，通过网络连接起来，共同协作完成任务。图片中分别展示了集中式、分散式、和分布式三种设计方法的示意图。 10 | 11 | ![1-1集中式、分散式、分布式示意图.png](./images/1-1集中式、分散式、分布式示意图.png) 12 | 13 | - 集中式系统：传统的数据库管理系统，如 Oracle、MySQL 和 Microsoft SQL Server 等，通常使用集中式模型。这些系统将所有数据存储在一个中央服务器上，并且客户端与服务器进行通信以访问和操作数据。另一个例子是源代码管理工具 Perforce，它使用中央服务器来存储代码库并进行版本控制。 14 | - 分布式系统：大规模的分布式计算系统，例如 Apache Hadoop 和 Apache Spark 等，将数据和计算任务分配到多个计算机节点上进行处理。每个节点都可以独立地执行任务，并使用通信协议进行交互。Google 的 MapReduce 框架也是一个分布式系统的示例，它用于处理大规模的数据集。 15 | - 分散式系统：比特币网络是一个分散式系统的典型示例。在比特币网络中，所有节点都是对等的，并且可以独立地处理交易请求。这种模型具有高度冗余性，因为即使其中一个节点失败，整个系统也会继续工作。另一个例子是 IPFS（Inter Planetary File System），它是一个完全去中心化的文件共享协议，用户可以通过该协议安全地共享文件和信息。 16 | 17 | ## 版本控制系统 18 | 19 | 版本控制系统是一种可以追踪和管理文件修改历史的工具。 20 | 21 | ### 为什么需要版本控制系统？ 22 | 23 | 在软件开发过程中，版本控制系统（Version Control System，VCS）是一种非常重要的工具。它可以跟踪代码库中所有文件和目录的历史记录，并允许多个开发人员同时在同一个代码库上工作。下面介绍为什么需要版本控制系统： 24 | 25 | 1. 历史记录和版本管理：版本控制系统可以记录每次代码提交的变化，并使您能够查看、比较和还原以前的版本。这对于查找错误、测试新功能或回滚更改等任务非常有用。 26 | 2. 多人协作：版本控制系统允许多个开发人员同时在同一个代码库上工作，而不会导致冲突或文件覆盖。它可以帮助团队协作，避免代码冲突，并使团队成员能够轻松地共享和审查彼此的更改。 27 | 3. 分支和合并：版本控制系统允许创建分支，这些分支可以包含独立的代码变更。这使得开发人员可以同时处理多个问题或尝试新功能，而不影响主要代码库。分支还允许您将单独的更改合并回主代码库，从而将多个代码分支合并为一个整体。 28 | 4. 跨平台和备份：版本控制系统可以在不同的操作系统和平台上运行，并且可以轻松地备份代码库以避免数据丢失或损坏。这使得团队成员能够在不同的机器上工作，而不必担心文件同步或版本问题。 29 | 5. 可追溯性和审核：版本控制系统可以记录谁做了什么更改，并在需要时提供审计跟踪。这对于保持代码安全、维护产品质量和满足合规要求非常重要。 30 | 31 | 总之，分布式版本控制系统可以让你轻松地管理你的文档和修改，并且保证你的文件不会丢失或损坏。 32 | 33 | 最后再重复一遍，Git 是现在最受欢迎的分布式版本控制系统，可以说是行业标准，用于跟踪管理代码或者文档，并且它是免费、开源的。是 IT 从业人员必学的一项技能。 34 | -------------------------------------------------------------------------------- /Git/10.切换版本.md: -------------------------------------------------------------------------------- 1 | # 10.切换版本 2 | 3 | ## 解释 4 | 5 | Git 切换版本是指在一个 Git 仓库中切换代码库到不同的提交历史记录上。我们每使用 `commit` 提交一次，对于 Git 来说，就是新建了一个版本。Git 提供了 `checkout` 命令，帮助我们实现版本切换的功能。 6 | 7 | 这对于软件开发人员来说非常有用，因为我们可以： 8 | 9 | - 查看代码库的早期版本：通过切换到旧的提交历史记录，开发人员可以查看代表项目过去状态的代码版本。这对于理解特定问题的起源或查看代码如何随时间演变很有用。 10 | - 比较不同版本之间的更改：通过切换到两个不同的提交记录，开发人员可以比较两个版本之间的代码差异。这对于查找错误或检查某段代码的功能变化等情况非常有用。 11 | - 回退到以前的版本：如果当前的代码库出现严重问题或错误，并且无法手动修复，开发人员可以切换回以前的版本，并从那里重新开始工作。 12 | 13 | ## 实验 14 | 15 | 我们进入终端，输入以下命令 16 | 17 | ```powershell 18 | # 查看提交日志 19 | $ git hist 20 | * d7f681f 2023-05-05 | Added abc to the test.txt (HEAD -> master) [aku] 21 | * 01b8702 2023-05-05 | Add first file [aku] 22 | 23 | # 查看文件内容 24 | $ cat .\test.txt 25 | abc 26 | ``` 27 | 28 | 我们可以看到之前实验提交的两条记录。同时打开 test 文件，观察文件状态。我们现在切回到第一次提交的版本，复制哈希值 `bc0c3f0`（请复制自己的哈希值） 29 | 30 | ```powershell 31 | # 切换指定版本 32 | $ git checkout 01b8702 33 | Note: switching to '01b8702'. 34 | 35 | You are in 'detached HEAD' state. You can look around, make experimental 36 | changes and commit them, and you can discard any commits you make in this 37 | state without impacting any branches by switching back to a branch. 38 | 39 | If you want to create a new branch to retain commits you create, you may 40 | do so (now or later) by using -c with the switch command. Example: 41 | 42 | git switch -c 43 | 44 | Or undo this operation with: 45 | 46 | git switch - 47 | 48 | Turn off this advice by setting config variable advice.detachedHead to false 49 | 50 | HEAD is now at 01b8702 Add first file 51 | 52 | $ cat .\test.txt 53 | 54 | ``` 55 | 56 | 命令执行后，会给一段提示，告诉我们现在所处的状态以及我们可以操作的选项。之前 test 文件添加的 abc 已经没有了。我们还可以再切换回去，输入`git checkout master` 命令切换回最新版本。本节内容只需要大家掌握切换版本的功能，checkout 还有其它功能。 57 | -------------------------------------------------------------------------------- /Git/02.Git的特性.md: -------------------------------------------------------------------------------- 1 | # 02.Git 的特性 2 | 3 | ## 以快照的方式存储 4 | 5 | 在 Git 中，每次提交都会创建一个新的快照，该快照包含了当前项目目录中所有文件和子目录的完整副本。这意味着用户可以轻松地浏览项目的任何历史版本，并且可以很容易地恢复到以前的某个特定版本。 6 | 7 | 当用户对项目进行更改时，Git 会计算出文件的差异并将其存储为新的快照。如果文件没有被修改，则 Git 只是链接到之前的版本，从而提高了存储效率和速度。 8 | 9 | 由于 Git 使用快照来管理项目的版本，因此它比其他版本控制系统具有许多优势，包括： 10 | 11 | 1. 更快的速度：由于 Git 存储文件的差异而不是整个文件，因此它能够更快地执行操作，如提交、分支、合并等。 12 | 2. 更少的存储空间：由于 Git 只存储文件的差异，因此它需要比其他版本控制系统更少的存储空间来存储项目的历史记录。 13 | 3. 更容易的备份和恢复：由于 Git 存储每个版本的整个项目目录状态快照，因此它可以轻松地进行备份和恢复操作。 14 | 15 | ## 几乎所有操作都是本地执行 16 | 17 | Git 几乎所有操作都可以在本地执行。由于 Git 是一款分布式版本控制系统，每个开发人员都拥有一个完整的代码副本，并且可以在本地进行更改和提交。这使得 Git 可以快速、高效地处理大量的操作，而不需要频繁地从远程存储库获取数据。 18 | 19 | 以下是一些在本地执行的 Git 操作： 20 | 21 | 1. 初始化仓库：可以在本地文件系统上创建一个新的 Git 仓库，无需与任何远程存储库通信。 22 | 2. 添加和删除文件：可以在本地文件系统上添加、删除和重命名文件，然后将更改提交到本地 Git 仓库。 23 | 3. 提交更改：可以在本地 Git 仓库中提交更改，记录当前工作目录的状态快照。 24 | 4. 切换分支：可以在本地切换分支，无需从远程存储库获取数据。 25 | 5. 合并分支：可以在本地将一个分支的更改合并到另一个分支中，无需与远程存储库通信。 26 | 6. 查看历史记录：可以在本地查看项目历史记录，包括提交、分支等信息。 27 | 7. 回滚更改：可以在本地回滚之前的提交，恢复到之前的状态。 28 | 8. 推送和拉取更改：虽然将更改推送到远程存储库和从远程存储库拉取更改是必要的，但这些操作其实是在本地执行的。 29 | 30 | ## 保证数据完整性 31 | 32 | 在 Git 中，每个文件或目录在存储之前都会被生成一个校验和并以此来标识。这意味着如果没有通知 Git，不能更改任何文件或目录的内容。Git 在其哲学最深层次内内置了这种机制，并且确保数据的完整性。这也就意味着，在传输中不会损失信息或出现文件损坏而不被 Git 检测到。 33 | 34 | Git 使用 SHA-1 哈希作为校验和生成算法。这是一个由十六进制字符（0-9 和 a-f）组成的 40 位字符串，基于存储在 Git 中文件或目录结构的内容计算得出。SHA-1 哈希值看起来像这样： 35 | 36 | ```hash 37 | 24b9da6552252987aa493b52f8696cd6d3b00373 38 | ``` 39 | 40 | 在 Git 中，你会经常看到这些哈希值，因为 Git 在存储时使用它们。事实上，在 Git 中，文件名并不重要，重要的是内容的哈希值，它可以唯一地标识某个文件。 41 | 42 | 哈希函数是一种单向函数，它将输入数据转换为一个固定长度的哈希值，并且该过程不可逆，还可以用于数据索引或加密等领域。 43 | 44 | ## 一般只添加数据 45 | 46 | 在 Git 中执行操作时，几乎所有操作都只是将数据添加到 Git 数据库中。很难让系统执行任何不可撤消的操作或者以任何方式擦除数据。和其他版本控制系统一样，您可能会在提交之前丢失或损坏尚未提交的更改，但是如果您经常将数据库推送到另一个仓库，那么在 Git 中提交快照后，非常难以失去这些提交，这使得使用 Git 变得非常愉快。 47 | -------------------------------------------------------------------------------- /Git/14.还原修改-已提交状态下.md: -------------------------------------------------------------------------------- 1 | # 14.还原修改-已提交状态下 2 | 3 | 本节将学习如何撤销提交，也就是我们执行了 git commit 操作后，Git 会将我们的提交保存至版本库。 4 | 5 | ## 修改文件，并提交版本库 6 | 7 | 在 test 文件中添加一行 123，并保存。使用 `git commit -a -m "Added 123"` 命令提交至版本库。 8 | 9 | ```powershell 10 | # 查看文件内容 11 | $ cat .\test.txt 12 | abc 13 | 123 14 | 15 | # 提交到版本库 16 | $ git commit -a -m "Added 123 to the test.txt" 17 | [master ed5fe0d] Added 123 to the test.txt 18 | 1 file changed, 2 insertions(+), 1 deletion(-) 19 | 20 | # 查看提交日志 21 | $ git hist 22 | * 375f4fe 2023-05-05 | Added 123 to the test.txt (HEAD -> master) [aku] 23 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 24 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 25 | ``` 26 | 27 | ## 还原提交 28 | 29 | `git revert` 是一个用于撤销 Git 仓库中先前提交的命令。它可以创建一个新的提交，该提交撤销以前提交所做的更改。 30 | 31 | 以下是一些 `git revert` 命令的示例： 32 | 33 | - `git revert HEAD`: 撤销最后一次提交，并创建一个新的提交来还原更改。 34 | - `git revert `: 撤销指定提交并创建一个新的提交来还原更改。`` 是要撤销的提交的 SHA 值。 35 | - `git revert -n `: 在不自动提交的情况下撤销指定提交。`-n` 或 `--no-commit` 选项告诉 Git 不要自动提交新的更改，而是等待用户手动提交更改。 36 | 37 | 请注意，在使用 `git revert` 命令时会创建一个新的提交，该提交将撤销以前提交所做的更改。因此，`git revert` 命令不会破坏 Git 仓库的历史记录，而是将其修改为包括还原更改的新提交。 38 | 39 | ```powershell 40 | # 撤销最后一次提交，并创建一个新的提交来还原更改。`--no-edit` 跳过编辑提交消息的步骤 41 | $ git revert HEAD --no-edit 42 | [master 6027826] Revert "Added 123 to the test.txt" 43 | 44 | #查看日志 45 | $ git hist 46 | * 1ca1854 2023-05-05 | Revert "Added 123 to the test.txt" (HEAD -> master) [aku] 47 | * 375f4fe 2023-05-05 | Added 123 to the test.txt [aku] 48 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 49 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 50 | 51 | # 查看文件 52 | $ cat .\test.txt 53 | abc 54 | ``` 55 | 56 | `HEAD` 是一个指针，它始终指向当前所在的本地分支的最新提交。此处也可以使用哈希值，比如 `git revert ed5fe0d` 57 | -------------------------------------------------------------------------------- /Git/16.修改提交内容.md: -------------------------------------------------------------------------------- 1 | # 16.修改提交内容 2 | 3 | ## 修改文件，并提交版本库 4 | 5 | 在 test 文件中添加一行 123，并保存。使用 `git commit -a -m "Added 123 to the test.txt"` 命令提交至版本库。 6 | 7 | ```bash 8 | # 查看文件内容 9 | $ cat .\test.txt 10 | abc 11 | 123 12 | 13 | # 提交到版本库 14 | $ git commit -a -m "Added 123 to the test.txt" 15 | [master ed5fe0d] Added 123 16 | 1 file changed, 2 insertions(+), 1 deletion(-) 17 | 18 | # 查看提交日志 19 | $ git hist 20 | * fc49e5f 2023-05-05 | Added 123 to the test.txt (HEAD -> master) [aku] 21 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 22 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 23 | ``` 24 | 25 | ## 再次修改文件，并覆盖上一次提交的内容 26 | 27 | ```bash 28 | # 查看文件内容 29 | $ cat .\test.txt 30 | abc 31 | 123456 32 | 33 | # 提交到版本库 34 | $ git commit -a -m "Added 123456 to the test.txt" --amend 35 | [master 929f644] Added 123456 to the test.txt 36 | Date: Fri May 5 19:25:32 2023 -0700 37 | 1 file changed, 2 insertions(+), 1 deletion(-) 38 | 39 | # 查看提交日志 40 | $ git hist 41 | * 929f644 2023-05-05 | Added 123456 to the test.txt (HEAD -> master) [aku] 42 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 43 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 44 | ``` 45 | 46 | ## 解释 47 | 48 | `--amend` 是一个 Git 命令选项，用于修改最新的提交（或当前分支上的指定提交）而无需创建新的提交记录。它可以用于更改引导提交或添加/删除文件等操作。 49 | 50 | 该选项主要用于以下两个情况： 51 | 52 | 1. 修改最新的提交：如果您忘记将某个文件提交到最新的提交中，或者需要修改提交消息，则可以使用 `git commit --amend` 命令来修改最新的提交。这将会打开编辑器并允许您修改提交消息和暂存区中的文件版本。完成修改后，Git 将更新最新的提交记录而无需创建新的提交记录。 53 | 54 | 2. 添加/删除文件：如果您想将文件添加到最新的提交中，或者从最新的提交中删除文件，则也可以使用 `git commit --amend` 命令完成此操作。首先，使用 `git add` 命令将更改的文件添加到暂存区中。接下来，运行 `git commit --amend` 命令，并使用 `--no-edit` 选项以保留现有的提交消息不变。Git 将会使用暂存区中的文件替换最新的提交记录，而无需创建新的提交记录。 55 | 56 | 请注意，在使用 `--amend` 选项时，请确保仅更改了最新的提交并且没有共享该提交，否则可能会破坏团队成员的工作进程。如果您已经共享了提交，则应使用 `git revert` 命令来逆转该提交，而不是修改它。 57 | -------------------------------------------------------------------------------- /Git/31.创建一个跟踪分支.md: -------------------------------------------------------------------------------- 1 | # 31.创建一个跟踪分支 2 | 3 | ## 实验 4 | 5 | 学习如何添加一个跟踪远程分支的本地分支。 6 | 以remotes/origin开头的分支是原始仓库中的分支。请注意，你不再拥有名为 lgnew 的分支，但它知道原始仓库有一个lgnew分支。 7 | 8 | ```bash 9 | # 创建跟踪远程分支的本地分支 10 | $ git branch --track lgnew origin/lgnew 11 | branch 'lgnew' set up to track 'origin/lgnew'. 12 | 13 | # 列出所有分支 14 | git branch -a 15 | lgnew 16 | * master 17 | remotes/origin/HEAD -> origin/master 18 | remotes/origin/lgnew 19 | remotes/origin/master 20 | 21 | # 查看提交历史 22 | $ git hist --max-count=2 23 | * b4e913c 2023-05-06 | Added README.md (HEAD -> master, origin/master, origin/HEAD) [aku] 24 | * 2456c71 2023-05-05 | Added teset2.txt (origin/lgnew, lgnew) [aku] 25 | ``` 26 | 27 | 我们现在可以在分支列表和日志中看到 `lgnew`分支。你可以查看28.从原始仓库获取更改中的输出信息以对比![[28.从原始仓库获取更改#^6c8fc8]] 28 | 29 | ## 跟踪分支是什么，有什么用？ 30 | 31 | 跟踪分支是指将本地分支与远程分支进行关联，使它们保持同步。具体而言，跟踪分支允许你在本地创建一个与远程分支相关联的分支，使得在推送、拉取和合并代码时更加方便。 32 | 33 | 以下是跟踪分支的几个主要用途和好处： 34 | 35 | 1. **远程仓库同步：** 跟踪分支使得你能够将本地分支与远程分支保持同步。你可以将本地分支的更改推送到远程分支，或者从远程分支拉取最新的更改到本地分支，从而确保你的代码与团队中的其他成员保持一致。 36 | 2. **方便的远程操作：** 有了跟踪分支，你可以更方便地进行远程操作，如推送和拉取代码，而无需每次都指定远程分支的名称。Git 会自动将你的本地分支与相关联的远程分支进行同步。 37 | 3. **清晰的分支关系：** 跟踪分支可以帮助你更清晰地了解本地分支与远程分支之间的关系。通过查看分支列表，你可以看到哪些分支正在跟踪远程分支，以及它们之间的关联关系。 38 | 4. **合并和拉取请求：** 跟踪分支对于合并和拉取请求（Pull Request）非常有用。在许多协作开发的场景中，团队成员会在自己的分支上进行开发，并通过合并或拉取请求将更改合并到主分支。通过跟踪分支，你可以轻松地将你的分支与目标分支（如主分支）进行关联，并创建合并请求，以便团队成员审查和合并你的更改。 39 | 40 | 总之，跟踪分支提供了一种便捷的方式来管理本地分支与远程分支之间的关系，使得代码的推送、拉取和合并操作更加简单和直观。通过使用跟踪分支，你可以更好地协作、保持代码同步，并更好地管理你的 Git 代码库。 41 | 42 | ## 什么时候需要创建跟踪分支 43 | 44 | 1. **从远程分支开始新的开发工作：** 当你要从远程分支（如主分支）开始新的开发工作时，创建一个跟踪分支可以让你在本地进行开发，并与远程分支进行同步。这样做可以确保你的更改与团队中的其他成员保持同步，并且可以更轻松地将你的更改合并回远程分支。 45 | 2. **合作开发和协作工作：** 在协作开发和协作工作的场景中，每个团队成员通常都在自己的分支上进行开发，并最终将更改合并到共享分支（如主分支）。通过创建跟踪分支，每个成员可以在本地维护自己的分支，并将其与共享分支进行关联，以便更好地进行代码审查、合并和跟踪更改。 46 | 3. **修复 bug 或进行实验性开发：** 如果你需要修复一个特定的 bug 或者进行一些实验性的开发工作，可以通过创建跟踪分支来隔离这些更改。这样做可以确保你的修改不会直接影响主分支或其他正在进行的工作，并且可以更轻松地跟踪和管理这些特定的更改。 47 | 4. **长期特性分支：** 在某些情况下，你可能需要创建一个长期存在的特性分支（Feature Branch），用于持续开发和实现某个特定的功能。通过创建跟踪分支，你可以在本地进行功能开发，并将其与远程分支进行同步，以便与其他团队成员进行协作、测试和审查。 48 | -------------------------------------------------------------------------------- /Git/35.托管Git仓库.md: -------------------------------------------------------------------------------- 1 | # 35.托管 Git 仓库 2 | 3 | ## 实验 4 | 5 | 设置 Git 守护进程 (Git Daemon) 共享Git 存储库。 6 | 7 | ```powershell 8 | # 在存储库的上级目录执行 9 | $ ls 10 | Directory: C:\Users\aku\Desktop 11 | 12 | Mode LastWriteTime Length Name 13 | ---- ------------- ------ ---- 14 | d---- 2023/5/6 2:52 cloned_git_learnnig 15 | d---- 2023/5/6 11:54 git_learning 16 | d---- 2023/5/6 2:47 git_learning_git 17 | 18 | # 开启守护进程 19 | $ git daemon --verbose --export-all --base-path=. --enable=receive-pack --reuseaddr 20 | [6608] Ready to rumble 21 | ``` 22 | 23 | 新开一个窗口访问 24 | 25 | ```powershell 26 | # 查看当前路径 27 | $ pwd 28 | Path 29 | ---- 30 | C:\Users\aku\Desktop 31 | 32 | # 执行克隆 33 | $ git clone git://localhost/git_learning net_git 34 | Cloning into 'net_git'... 35 | remote: Enumerating objects: 38, done. 36 | remote: Counting objects: 100% (38/38), done. 37 | remote: Compressing objects: 100% (25/25), done. 38 | remote: Total 38 (delta 1), reused 0 (delta 0), pack-reused 0 39 | Receiving objects: 100% (38/38), done. 40 | Resolving deltas: 100% (1/1), done. 41 | ``` 42 | 43 | 查看新克隆库文件内容 44 | 45 | ```powershell 46 | $ ls .\net_git\ 47 | Directory: C:\Users\aku\Desktop\net_git 48 | 49 | Mode LastWriteTime Length Name 50 | ---- ------------- ------ ---- 51 | d---- 2023/5/6 12:06 lab 52 | -a--- 2023/5/6 12:06 27 .gitignore 53 | -a--- 2023/5/6 12:06 59 README.md 54 | ``` 55 | 56 | ## Git 托管的其它信息 57 | 58 | 1. 使用 Git 托管服务 59 | 有许多受信任的 Git 托管服务可供选择，例如 GitHub、GitLab 和 Bitbucket。这些服务提供了一个 Web 界面，用于管理存储库、团队和权限，并允许您轻松地与其他人共享代码。您可以使用这些服务中的任何一个来托管您的 Git 存储库，并根据需要设置公共或私有访问权限。 60 | 2. 搭建自己的 Git 服务器 61 | 如果您希望完全控制自己的 Git 存储库，那么您可以搭建自己的 Git 服务器。有几种方法可以实现这一点，包括使用 Gitosis 或 Gitolite 这样的工具来设置服务器，也可以直接在您的服务器上安装 Git 并手动设置存储库权限。无论哪种方法，都需要一定的技术知识和配置。 62 | 3. 在云端虚拟机中托管 Git 存储库 63 | 如果您希望在云端虚拟机中托管 Git 存储库，那么您可以使用 Amazon EC2、Microsoft Azure 或 Google Cloud Platform 等云计算平台来部署您的服务器。这些服务提供了虚拟机、存储和网络基础架构，使您能够快速和轻松地部署您的 Git 存储库，并根据需要进行扩展。 64 | -------------------------------------------------------------------------------- /Git/20.创建分支.md: -------------------------------------------------------------------------------- 1 | # 20.创建分支 2 | 3 | 在 Git 中，分支是指针，它指向某个提交记录。在 Git 存储库中，默认情况下有一个名为 `master` 的主分支，该分支指向最新的提交记录。 4 | 5 | 使用分支可以轻松地将代码库分成不同的版本，并在这些版本之间进行切换和合并操作。例如，如果你想尝试新功能或修复错误，可以创建一个新分支，在该分支上进行更改，而不会影响主分支。一旦更改准备好，就可以将其合并回主分支中。这使得协作变得更加容易，因为团队成员可以在自己的分支上开发新功能，而不必担心与其他人的更改冲突。 6 | 7 | ## 创建一个新分支 8 | 9 | 创建一个名为 lgnew 的新分支 10 | 11 | ```powershell 12 | # 新建分支 13 | $ git checkout -b lgnew 14 | Switched to a new branch 'lgnew' 15 | 16 | # 查看状态 17 | $ git status 18 | On branch lgnew 19 | nothing to commit, working tree clean 20 | ``` 21 | 22 | > `git checkout -b` 是 `git branch ` 和`git checkout ` 两个命令的快捷方式。 23 | 24 | ## 在此分支上新建一个文件并提交 25 | 26 | 我们在 lab 目录下，新建一个 test2.txt 文件，并提交 27 | 28 | ```powershell 29 | # 暂存 30 | git add .\lab\test2.txt 31 | # 提交 32 | $ git commit -m "Added teset2.txt" 33 | [lgnew ead2515] Added teset2.txt 34 | 1 file changed, 0 insertions(+), 0 deletions(-) 35 | create mode 100644 lab/test2.txt 36 | # 查看状态 37 | $ git status 38 | On branch lgnew 39 | nothing to commit, working tree clean 40 | ``` 41 | 42 | ## 切换主分支，创建一个新文件并提交 43 | 44 | 我们可以发现，我们在 lgnew 分支上的修改，并没有在主分支上显示。 45 | 46 | ```powershell 47 | # 切换主分支 48 | git checkout master 49 | 50 | # 查看状态 51 | git status 52 | 53 | # 暂存 54 | git add .\lab\test3.txt 55 | 56 | # 提交 57 | git commit -m "Added teset3.txt" 58 | [master da0a6f8] Added teset3.txt 59 | 1 file changed, 0 insertions(+), 0 deletions(-) 60 | create mode 100644 lab/test3.txt 61 | ``` 62 | 63 | ## 查看提交日志 64 | 65 | ```powershell 66 | git hist --all 67 | * 1c78eab 2023-05-05 | Added teset3.txt (HEAD -> master) [aku] 68 | | * 3d99c8f 2023-05-05 | Added teset2.txt (lgnew) [aku] 69 | |/ 70 | * 5dc8b1e 2023-05-05 | Added .gitignore [aku] 71 | * b77158a 2023-05-05 | Moved test.txt to lab [aku] 72 | * 929f644 2023-05-05 | Added 123456 to the test.txt [aku] 73 | | * 739560c 2023-05-05 | Oops,an error committed (tag: oops) [aku] 74 | | * 1ca1854 2023-05-05 | Revert "Added 123 to the test.txt" [aku] 75 | | * 375f4fe 2023-05-05 | Added 123 to the test.txt [aku] 76 | |/ 77 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 78 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 79 | ``` 80 | -------------------------------------------------------------------------------- /Git/28.从原始仓库获取更改.md: -------------------------------------------------------------------------------- 1 | # 28.从原始仓库获取更改 2 | 3 | ## 修改原始仓库并提交 4 | 5 | 我们在 `git_learnnig` 仓库的根目录下，添加一个新文件 README.md，并添加一行内容 ”Git Learnning“。然后提交 6 | 7 | ```powershell 8 | # 查看文件内容 9 | $ cat .\README.md 10 | Git Learnning 11 | 12 | # 暂存 13 | $ git add .\README.md 14 | 15 | # 提交 16 | $ git commit -m "Added README.md" 17 | [master b4e913c] Added README.md 18 | 1 file changed, 1 insertion(+) 19 | create mode 100644 README.md 20 | ``` 21 | 22 | ## 进入克隆仓库获取更改 23 | 24 | 进入 `cloned_git_learnning` 25 | 26 | ```powershell 27 | # 查看当前路径 28 | $ pwd 29 | Path 30 | ---- 31 | C:\Users\aku\Desktop\cloned_git_learnnig 32 | 33 | # 获取更新 34 | $ git fetch 35 | remote: Enumerating objects: 4, done. 36 | remote: Counting objects: 100% (4/4), done. 37 | remote: Compressing objects: 100% (2/2), done. 38 | remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 39 | Unpacking objects: 100% (3/3), 300 bytes | 16.00 KiB/s, done. 40 | From C:/Users/aku/Desktop/git_learning 41 | 2456c71..b4e913c master -> origin/master 42 | ``` 43 | 44 | ```powershell 45 | # 查看提交信息 46 | $ git hist --all 47 | * b4e913c 2023-05-06 | Added README.md (origin/master, origin/HEAD) [aku] 48 | * 2456c71 2023-05-05 | Added teset2.txt (HEAD -> master, origin/lgnew) [aku] 49 | * 1c78eab 2023-05-05 | Added teset3.txt [aku] 50 | * 31e5621 2023-05-05 | Added teset2.txt [aku] 51 | * 5dc8b1e 2023-05-05 | Added .gitignore [aku] 52 | * b77158a 2023-05-05 | Moved test.txt to lab [aku] 53 | * 929f644 2023-05-05 | Added 123456 to the test.txt [aku] 54 | | * 739560c 2023-05-05 | Oops,an error committed (tag: oops) [aku] 55 | | * 1ca1854 2023-05-05 | Revert "Added 123 to the test.txt" [aku] 56 | | * 375f4fe 2023-05-05 | Added 123 to the test.txt [aku] 57 | |/ 58 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 59 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 60 | ``` 61 | 62 | ^6c8fc8 63 | 64 | 此时，存储库已经包含了原始存储库的所有提交记录，但它们尚未集成到克隆存储库的本地分支中。在上面的历史记录中找到`Added README.md`提交。请注意，该提交包括`origin/master`和`origin/HEAD`。 65 | 现在看一下`Added teset2.txt`提交。你会发现本地主分支指向这个提交，而不是我们刚刚获取的新提交。 66 | 总之，`git fetch`命令将从远程存储库获取新的提交记录，但它不会将这些提交合并到本地分支中。 67 | 68 | ## 查看 README.md 69 | 70 | 我看到了提交信息，克隆库里并没有此文件. 71 | -------------------------------------------------------------------------------- /summary.ps1: -------------------------------------------------------------------------------- 1 | $folderPath = Get-Location 2 | $summaryFile = Join-Path -Path $folderPath -ChildPath "SUMMARY.md" 3 | 4 | # 指定要排除的文件夹列表 5 | $excludedFolders = @("images") 6 | # 指定要排除的文件类型 7 | $excludedExtensions = @(".png", ".ps1") 8 | # 指定要排除的文件列表 9 | $excludedFiles = @("SUMMARY.md") 10 | 11 | #文件名称检查 12 | # 获取所有的文件 13 | Get-ChildItem -Path $folderPath -Recurse -File | ForEach-Object { 14 | $newname = $_.Name.Replace(" ", "") # 将文件名中的空格替换为空格 15 | if ($newname -ne $_.Name) { # 如果文件名发生了更改 16 | Rename-Item -Path $_.FullName -NewName $newname 17 | } 18 | } 19 | 20 | # 获取所有的文件夹 21 | Get-ChildItem -Path $folderPath -Recurse -Directory | ForEach-Object { 22 | $newname = $_.Name.Replace(" ", "") # 将文件夹名中的空格替换为空格 23 | if ($newname -ne $_.Name) { # 如果文件夹名发生了更改 24 | Rename-Item -Path $_.FullName -NewName $newname 25 | } 26 | } 27 | 28 | function GenerateSummary { 29 | param ( 30 | [string]$path, 31 | [string]$indentation = "" 32 | ) 33 | 34 | $items = Get-ChildItem -Path $path | Sort-Object -Property Name 35 | 36 | foreach ($item in $items) { 37 | if ($item.PSIsContainer) { 38 | if ($excludedFolders -notcontains $item.Name) { 39 | $itemName = $item.Name + "/" 40 | Write-Output "$indentation* [$itemName]($itemName)" 41 | GenerateSummary -path $item.FullName -indentation (" " + $indentation) 42 | } 43 | } 44 | else { 45 | if ($excludedExtensions -notcontains $item.Extension.ToLower() -and $excludedFiles -notcontains $item.Name) { 46 | $itemName = $item.Name -replace '\.[^.]+$' -replace '\s', '' 47 | $itemPath = $item.FullName.Replace($folderPath, "").Replace("\", "/").TrimStart("/") 48 | Write-Output "$indentation* [$itemName]($itemPath)" 49 | } 50 | } 51 | } 52 | } 53 | 54 | $summaryContent = @("", "# Summary", "") 55 | $summaryContent += GenerateSummary -path $folderPath 56 | 57 | $summaryContent | Out-File -FilePath $summaryFile -Encoding utf8 58 | 59 | Write-Output "summary.md 文件已生成在 $summaryFile" 60 | -------------------------------------------------------------------------------- /Git/05.初始配置.md: -------------------------------------------------------------------------------- 1 | # 05.初始配置 2 | 3 | 在正式使用 Git 创建并管理项目前，我们还需要对 Git 进行初始的配置。Git 提供了 git config 工具，来帮助我们进行配置。我们来试一试吧，打开终输入 4 | 5 | ```powershell 6 | git config --list --show-origin 7 | ``` 8 | 9 | 我们可以查看所有的配置以及它们所在的文件信息。 10 | 11 | 终端中输出了配置文件名称、路径以及详细的配置项。Git 的配置文件总共有三个，分别存储在不同的地方，并对应不同的权限。 12 | 13 | 1. 存储在安装目录下etc路径下的 `gitconfig` 文件，它是系统全局配置文件，它包含系统上每一个用户及他们仓库的通用配置。 14 | 2. 在当前系统用户下的 `.gitconfig`文件，这是当前用户的全局配置文件，它存储了仓库都共享的通用配置选项。 15 | 3. 存储在仓库目录下的`.git/config`文件，是针对仓库的配置文件，它存储了仓库的配置信息。 16 | 17 | 这里问一个问题，假设三个配置文件都存储了同样一条配置信息，请问哪个配置文件的优先级最高？答案是仓库目录的优先级最高，其次是用户配置文件，最后是全局配置文件。 18 | 19 | > 配置文件是一种用来存储应用程序、系统或服务的设置信息的文件。这些文件通常以简单的文本格式写成，包含各种配置选项及其对应的值。使用配置文件可以让用户更方便地自定义和调整软件应用程序的各种设置，同时也能够简化软件的部署和维护工作。在实际应用中，配置文件还常常被用于支持不同平台或操作系统之间的兼容性，以及版本控制等功能。 20 | 21 | ## 设置用户名和邮箱 22 | 23 | 在 Git 中，一旦设置了用户名和邮箱地址，并将其提交到 Git 提交历史中，就不能直接更改它们。这是因为 Git 使用提交者的用户名和邮箱地址来跟踪每个提交的作者信息，并将其保存在版本控制历史记录中。如果您更改了用户名或邮箱地址，则之前的提交历史记录中的作者信息也会被随之更改。 24 | 25 | ```powershell 26 | git config user.name "名字" 27 | git config user.email "邮箱" 28 | ``` 29 | 30 | ## 修改默认编辑器为 VScode 31 | 32 | ```powershell 33 | git config --global core.editor "code --wait” 34 | ``` 35 | 36 | `code` 是 VSCode 运行程序名称，被写入到了环境变量，输入code 就可以调用VSCode，`--wait` 参数是 VSCode 的参数，是让 VSCode 以阻塞模式运行. 37 | >阻塞模式是一种程序运行方式，它会一直等待某个操作完成后才会继续执行下面的代码。在阻塞模式下，程序会暂停当前任务，等待某些条件满足后再继续执行下一步操作。在 VS Code 编辑器中，如果使用 `--wait` 参数以阻塞模式启动编辑器，则当您打开一个文件时，编辑器将会在文件保存并关闭后才退出并返回终端的控制权。这就确保了 Git 命令在等待编辑器中的操作完成后才会继续执行下一步操作。这对于集成编辑器和 Git 的操作非常有用，因为它可以确保 Git 在正确的时间点捕获并存储编辑器中所做的更改。 38 | 39 | 我们可以通过 `git config --list` 命令来查看配置信息，还可以通过 `git help` 来获取命令提示信息，也可以指定命令来查看帮助信息，比如，使用 git help config 来查看 config 的帮助信息 。 40 | 41 | >一个命令有三部分组成: 42 | > 43 | >- 命令名，表示要执行的操作，例如 git， 44 | >- 选项参数，用于修改命令的默认行为或者指定其他相关信息。选项参数通常以短横线（-）或双短横线（--）开头，如 `--list`,`--show-origin`。 45 | >- 参数值，用于指定命令需要操作的对象或者附加信息。参数值可以是文件名、目录名、URL 地址、IP 地址、用户名、密码等等，根据不同的命令和应用场景可能会有所不同。 46 | > 47 | > 48 | > 49 | >在 `git config --global core.editor "code --wait"` 中: 50 | > 51 | >- `git`是命令名，表示执行 Git 的相关操作 52 | >- `config` 是 Git 的子命令，用于管理和查询 Git 的配置信息 53 | >- `--global` 是选项参数，表示将修改应用于当前用户的全局 Git 配置文件， 54 | >- `core.editor`：参数值，表示要设置或修改的 Git 配置选项的名称。 55 | >- `"code --wait"`：参数值，表示要为 `core.editor` 选项设置的值，即使用 VS Code 编辑器，并添加 `--wait` 参数以阻塞模式启动。 56 | -------------------------------------------------------------------------------- /Git/13.撤销修改-已暂存状态下.md: -------------------------------------------------------------------------------- 1 | # 13.撤销修改-已暂存状态下 2 | 3 | ![1](images/13-1.png) 4 | 5 | 本节将学习撤销已暂存的状态，也就是我们更改了文件，并且使用 `git add` 命令，将更改提交到了暂存区。现在需要撤销已暂存的状态使用 `git status` 查看状态。我们输入 `git checkout master`，切换到主分支。 6 | 7 | ## 修改文件，并提交至暂存区 8 | 9 | 在 test 文件中添加一行 123，并保存。使用 `git add` 命令提交至暂存区。 10 | 11 | ```powershell 12 | # 查看文件内容 13 | $ cat .\test.txt 14 | abc 15 | 123 16 | 17 | # 添加到暂存区 18 | $ git add test.txt 19 | 20 | # 查看状态 21 | $ git status 22 | On branch master 23 | Changes to be committed: 24 | (use "git restore --staged ..." to unstage) 25 | modified: test.txt 26 | ``` 27 | 28 | ## 重置暂存区 29 | 30 | 现在我们尝试撤销操作，未提交的文件恢复命令使用的是 reset 命令，我们输入 `git reset HEAD test.txt` ，将文件移除暂存区。 31 | 32 | ```powershell 33 | # 撤销暂存文件 34 | $ git reset HEAD test.txt 35 | Unstaged changes after reset: 36 | M test.txt 37 | 38 | # 查看状态 39 | $ git status 40 | On branch master 41 | Changes not staged for commit: 42 | (use "git add ..." to update what will be committed) 43 | (use "git restore ..." to discard changes in working directory) 44 | modified: test.txt 45 | 46 | no changes added to commit (use "git add" and/or "git commit -a") 47 | ``` 48 | 49 | HEAD 是一个指针，它指向当前分支所在的提交。换句话说，它是指向当前工作目录所基于的最新提交的引用。在此处 HEAD 参数也可以省略。 50 | 51 | ## 恢复本地修改 52 | 53 | 现在要恢复文件状态，我们还得执行 [12.撤销修改-本地已保存状态](12.%E6%92%A4%E9%94%80%E4%BF%AE%E6%94%B9-%E6%9C%AC%E5%9C%B0%E5%B7%B2%E4%BF%9D%E5%AD%98%E7%8A%B6%E6%80%81.md)中的操作 54 | 55 | ```powershell 56 | # 撤销暂存前更改 57 | $ git checkout test.txt 58 | 59 | # 查看 Git 状态 60 | $ git status 61 | git status 62 | On branch master 63 | nothing to commit, working tree clean 64 | ``` 65 | 66 | ## reset 和 checkout 67 | 68 | `reset` 和 `checkout` 是 Git 中两个常用的命令，它们都可以用于将 HEAD 指针移动到其他提交或分支上。然而，它们之间有一些重要的区别： 69 | 70 | - `reset` 命令改变了当前分支的历史记录，并可以影响暂存区和工作目录的状态。例如，使用 `git reset --hard ` 命令将会重置当前分支的历史记录并强制更新工作目录和暂存区以匹配指定的提交。 71 | - `checkout` 命令则是切换到不同的分支或提交，但不会更改当前分支的历史记录。例如，使用 `git checkout ` 命令将会切换到指定的分支，并将 HEAD 指针移到该分支的最新提交上。 72 | 73 | 因此，在进行 Git 操作时，请根据您的需要选择正确的命令。如果您想要撤销某些更改并将历史记录回滚到旧的提交，则应使用 `reset` 命令。如果您只是想查看其他提交的状态或切换到不同的分支，则应使用 `checkout` 命令。 74 | 75 | 请注意，在使用这些命令之前，请务必先备份您的代码库并确保已经理解了命令所带来的影响。不正确使用这些命令可能会导致数据丢失或代码库处于不稳定状态。 76 | -------------------------------------------------------------------------------- /Git/08.查看提交历史.md: -------------------------------------------------------------------------------- 1 | # 08.查看提交历史 2 | 3 | 在程序开发过程中，了解项目的演变历史非常重要，因为它可以帮助您更好地理解代码库，并跟踪文件的变化。 Git 为我们提供了 `git log` 工具，用于查看 Git 代码库中的提交历史记录。首先我们先打开终端，进入项目目录，然后输入 `git log` 命令 4 | 5 | ```powershell 6 | $ git log 7 | commit d7f681fa3086bfa0222388775c827ab650e00a16 (HEAD -> master) 8 | Author: aku 9 | Date: Fri May 5 19:05:08 2023 -0700 10 | 11 | Added abc to the test.txt 12 | 13 | commit 01b8702bd46d5f4fcb18fc2d8523808b131a3ab6 14 | Author: aku 15 | Date: Fri May 5 19:04:04 2023 -0700 16 | 17 | Add first file 18 | ``` 19 | 20 | 在默认情况下，它会按时间顺序列出了所有提交，并提供有关每个提交的详细信息。输出格式包括提交哈希值、作者、提交日期、提交信息。 21 | 22 | > 哈希值是一种唯一且固定长度的字符串，由哈希函数根据输入数据计算而来。它通常用于检测数据完整性和安全性因为哈希函数是一种单向函数，它将输入数据转换为一个固定长度的哈希值，并且该过程不可逆，还可以用于数据索引或加密等领域。`git log` 还提供很多选项参数，帮助我们更好的查看信息，例如 `--pretty`，它用于指定在输出中显示提交信息的格式。允许用户自定义输出的样式。`--pretty=oneline` 可以把提交标记和信息显示在一行内。 23 | 24 | ```powershell 25 | $ git log --pretty=oneline 26 | d7f681fa3086bfa0222388775c827ab650e00a16 (HEAD -> master) Added abc to the test.txt 27 | 01b8702bd46d5f4fcb18fc2d8523808b131a3ab6 Add first file 28 | ``` 29 | 30 | 我们还可以用多种方式来控制输出结果，比如，只显示某个作者的提交。 31 | 32 | ```powershell 33 | $ git log --pretty=oneline --author="aku" 34 | d7f681fa3086bfa0222388775c827ab650e00a16 (HEAD -> master) Added abc to the test.txt 35 | 01b8702bd46d5f4fcb18fc2d8523808b131a3ab6 Add first file 36 | ``` 37 | 38 | ## 还有一些常用的命令 39 | 40 | ```powershell 41 | # 显示最近的两个提交记录 42 | $ git log --pretty=oneline --max-count=2 43 | # 显示五分钟前的所有提交记录 44 | $ git log --pretty=oneline --since='5 minutes ago' 45 | # 显示五分钟内的所有提交记录 46 | $ git log --pretty=oneline --until='5 minutes ago' 47 | # 显示当前分支上所有的提交历史 48 | $ git log --pretty=oneline --all 49 | ``` 50 | 51 | 还有非常多的选项，我们可以使用 `git log --help` 命令去查看详细帮助文档。 52 | 53 | ## 终极命令 54 | 55 | 随着提交越来越多，我们可以使用下面这条命令，它可以整洁的显示我们所需要的信息。 56 | 57 | ```powershell 58 | $ git log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short 59 | 60 | * d7f681f 2023-05-05 | Added abc to the test.txt (HEAD -> master) [aku] 61 | * 01b8702 2023-05-05 | Add first file [aku] 62 | ``` 63 | 64 | - `--pretty="..."`  定义输出的格式。 65 | - `%h` :提交哈希值的缩写 66 | - `%d` :提交所在的分支或标签等引用的名称 67 | - `%ad` :提交的作者修订日期 68 | - `%s` :提交的说明 69 | - `%an`:作者姓名 70 | - `--graph`:通知 git 以 ASCII 图形布局显示提交树（前面的 `*`） 71 | - `--date=short`:设置为短日期格式（YYYY-MM-DD） 72 | 73 | Git 还集成了一个让我们查看日志的图形化界面 gitk，我们在仓库目录输入 gitk 就会弹出这个工具。 74 | ![1](images/8-1.png) 75 | -------------------------------------------------------------------------------- /Git/06.创建本地仓库.md: -------------------------------------------------------------------------------- 1 | # 06.创建本地仓库 2 | 3 | 我们在本地新建一个 `git_learning` 的文件夹，创一个 `test.txt` 文件并使用终端打开目录。 4 | ![1](images/6-1.png) 5 | 6 | ## 实验 7 | 8 | 创建一个本地 Git 仓库，总共分为四步 9 | 10 | 1. 创建项目文件及文件夹； 11 | 2. 使用 git init 命令初始化仓库； 12 | 3. 使用 git add 命令，将文件变化信息添加到暂存区； 13 | 4. 使用 git commit 命令，将暂存区的修改信息提交到版本库。 14 | 15 | ```powershell 16 | # 初始化仓库 17 | git init 18 | # 查看仓库状态 19 | git status 20 | # 追踪 test.txt 文件 21 | git add test.txt 22 | # 提交至版本库 23 | git commit -m "Add first file" 24 | ``` 25 | 26 | ## 三个区域 27 | 28 | ![2](images/6-2.png) 29 | 30 | 这里面涉及到 Git 的三个重要的概念，即工作区、暂存区、版本库。 31 | 32 | 1. 工作区是指包含项目代码的本地目录，是我们平常在编辑器中修改和操作的目录。比如上节新建的 text.txt 文件。粗暴一点说，除去.git文件及目录就是工作区。 33 | 2. 暂存区是用于存储即将被提交到版本库中的文件快照。暂存区实际上是一个文件，它存储在仓库目录下的 .git目录下的 index。Git 会将当前工作目录中已修改的文件的快照存储在暂存区，然后可以通过 git status 命令来查看暂存区和工作目录之间的差异。 34 | 3. 版本库是 Git 用来保存项目历史记录的地方，包含了所有的提交记录和文件变更。版本库通常保存在 .git 目录中，包含 Git 对象数据库、分支引用信息、标签引用信息、提交日志等。 35 | 36 | ### 为什么需要暂存区？ 37 | 38 | 第一次接触到暂存的兄弟，可能会有这样的疑问，我已经完成了文件编辑，直接帮我保存就行了，为什么还要引入暂存的概念呢。 39 | 40 | - 首先，我们需要精细化控制，当我们对多个文件进行更改时，我们需要多次审查文件有没有修改正常，如果直接提交，会导致很多问题，引入暂存区，可以让我们在提交前，先预览和审查，然后决定是否上传。不是所有修改过的文件都要上传，假如我们修改过A、B两个文件，B文件没处理完毕，我们可以先上传A文件。也就是部分提交的功能。 41 | - 其次，避免出现误操作，我们将修改和提交分离开，可以很好的控制代码版本，避免更改的文件不会影响到其它部分的文件。 42 | - 最后就是方便协作，在团队协作开发的情况下，使用 Git 暂存区可以避免多人同时修改同一份代码造成的冲突和错误。每个人可以将自己的更改添加到暂存区，并在完成更改后逐一提交。这样可以让每个人更好地管理自己的更改，并及时解决冲突。 43 | 44 | ## 文件的三个状态 45 | 46 | 在 Git 中的文件也存在三种状态，已修改、已暂存、已提交。 47 | 48 | 已修改（modified）：表示文件已被修改但尚未被暂存。我们在工作区修改了文件，并点击了保存，这时候文件状态会变成已修改。也就是说，你已经对文件进行了更改，但还没有使用 `git add`命令将其添加到暂存区域。 49 | 50 | 已暂存（staged）：表示对一个已修改文件的当前版本做出了标记，以便在下一次提交时将其纳入版本控制。也就是说，使用 `git add` 命令将修改的文件添加到暂存区域中。 51 | 52 | 已提交（committed）：表示数据已经被安全地保存在本地数据库中。也就是说，在你执行了 `git commit` 命令之后，所有的更改都被保存到了 Git 仓库的历史记录中。 53 | 54 | >这里可能有兄弟会有疑问，我们操作的时候，不是有一个未追踪的文件状态存在吗，怎么这里只有三个？ 55 | > 56 | >![3](images/6-3.png) 57 | > 58 | >在 Git 中，已追踪（tracked）和未追踪（untracked）是描述文件或目录状态的概念，与文件的三种状态（已提交、已修改、已暂存)有所不同。一个已追踪文件是受 Git 版本控制管理的文件，即该文件已经被添加到了 Git 数据库中，并且可以使用 `git status` 命令查看其状态。 59 | > 60 | >相反，一个未追踪文件是未被 Git 跟踪的文件，即该文件尚未被添加到 Git 数据库中。通常情况下，如果你使用 `git add` 命令将一个未追踪文件添加到 Git 中，那么该文件就会变成已追踪文件，并且可以被提交和管理。但是，如果你永久地删除了一个已追踪文件，那么它就会变成未追踪文件。在 `git status` 命令输出中，已追踪文件可能有几种不同的状态，包括已修改、已暂存或未被修改。未追踪文件只会在 `git status` 输出中显示一次，并被列为未跟踪文件。 61 | 62 | ## 看看我们的仓库里有什么？ 63 | 64 | 当我们执行了 `git init` 初始化仓库之后，Git 会创建一个 .git 文件夹，下面是一些文件信息 65 | 66 | 1. `HEAD`：指向当前活动分支的指针。 67 | 2. `config`：版本库的配置文件，包括用户名、邮件地址、编辑器等信息。 68 | 3. `description`：用于在 GitWeb 等工具中显示有关版本库的描述信息。 69 | 4. `hooks/`：包含可自定义的 Git 钩子脚本，用于实现特定功能或执行自动化任务。 70 | 5. `objects/`：包含 Git 对象数据库，其中存储了版本库中所有的文件和提交历史记录。 71 | 6. `refs/`：包含分支和标签的指针文件，其中保存了每个分支和标签及其所指向的提交 ID。 72 | 7. `index`：暂存区的索引文件，用于记录下一次提交要包括的文件。 73 | -------------------------------------------------------------------------------- /Git/11.标签操作.md: -------------------------------------------------------------------------------- 1 | # 11.标签操作 2 | 3 | 在 Git 中，标签是一种用于为代码库中的特定版本打上标记的方法。它通常用于标记软件的重要版本，以便用户或开发人员更容易地识别和访问它们。 4 | 5 | ## 打标签 6 | 7 | 下面进行操作，Git 提供了`tag` 命令，使用 `git tag`加上标签名字，比如使用 `git tag v1` 即可命名当前版本为 v1 版本。在操作前，请确认你所在的分支。 8 | 9 | ```powershell 10 | # 查看状态 11 | $ git status 12 | 13 | # 如果不在主分支，切换至主分支 14 | $ git checkout master 15 | 16 | ``` 17 | 18 | 将最新提交打上标签 v1，将第一次提交打上标签 v1-beta 19 | 20 | ![1](images/11-1.png) 21 | 22 | ```powershell 23 | # 把最新一次提交标记为 v1 24 | $ git tag v1 25 | 26 | # 查看提交信息 27 | $ git hist 28 | * d7f681f 2023-05-05 | Added abc to the test.txt (HEAD -> master) [aku] 29 | * 01b8702 2023-05-05 | Add first file [aku] 30 | ``` 31 | 32 | 上节我们聊到切换版本，使用的是哈希值去定位，我们现在可以用标签去定位，比如我们现在想回到v1版本的上一个版本(v1的父级)，也就是我们的第一次提交，并打上一个标签 v1-beta。 33 | 34 | 可以进行如下操作， 35 | 36 | ```powershell 37 | # 切换至 v1 的父级 38 | $ git checkout v1^ 39 | ... 40 | HEAD is now at bc0c3f0 Add first file 41 | 42 | # 打上标记 43 | $ git tag v1-beta 44 | 45 | # 显示当前可用的标签 46 | $ git tag 47 | v1 48 | v1-beta 49 | 50 | # 显示所有分支的提交历史记录。 51 | $ git hist master --all 52 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1, master) [aku] 53 | * 01b8702 2023-05-05 | Add first file (HEAD, tag: v1-beta) [aku] 54 | 55 | ``` 56 | 57 | 在 Git 中，`^` 符号 (carrot) 表示引用前一个提交。它可以与分支名、标签名或者提交 SHA-1 值一起使用，并指示 Git 跳过该提交的父提交，以便获取更早的提交。 58 | 59 | 下面是一些常见的在 Git 中使用 `^` 符号的示例： 60 | 61 | - `HEAD^`：引用当前提交的父提交。 62 | - `master^`：引用 master 分支上最新提交的父提交。 63 | - `v1.0^`：引用 v1.0 标签所指向的提交的父提交。 64 | - `abc123^`：引用 SHA-1 值为 abc123 的提交的父提交。 65 | 66 | 除了单个 `^` 符号外，还可以使用多个 `^` 符号来引用更早的提交。例如，`HEAD^^` 表示当前提交的父提交的父提交，即当前提交之前的第二个提交。 67 | 68 | 此外，在提交历史中，一个提交通常有多个父提交（例如合并操作），这时 `^` 符号就不够用了。可以使用 `~` 符号来引用更远的祖先提交。例如，`HEAD~3` 表示当前提交之前的第三个提交，而 `HEAD~2^2` 则表示当前提交的第二个父提交的父提交。 69 | `^` 符号在 Git 中用于引用前一个提交，它可以与分支名、标签名或者提交 SHA-1 值一起使用，以获取更早的提交。 70 | 71 | ## 删除标签 72 | 73 | 删除标签使用`-d` 选项参数 74 | 75 | ```powershell 76 | git tag -d v1 77 | ``` 78 | 79 | ## 添加标签信息 80 | 81 | `-a` 选项参数表示创建一个带注释的标签； 82 | `v1` 表示标签的名称； 83 | `-m "Version 1.0 release"` 则表示对该标签的注释信息。 84 | 85 | ```powershell 86 | $ git tag -a v1 -m "Version 1" 87 | 88 | # 查看详细内容 89 | $ git show v1 90 | tag v1 91 | Tagger: aku 92 | Date: Fri May 5 19:15:39 2023 -0700 93 | 94 | Version 1 95 | 96 | commit d7f681fa3086bfa0222388775c827ab650e00a16 (HEAD -> master, tag: v1) 97 | Author: aku 98 | Date: Fri May 5 19:05:08 2023 -0700 99 | 100 | Added abc to the test.txt 101 | 102 | diff --git a/test.txt b/test.txt 103 | index e69de29..f2ba8f8 100644 104 | --- a/test.txt 105 | +++ b/test.txt 106 | @@ -0,0 +1 @@ 107 | +abc 108 | \ No newline at end of file 109 | ``` 110 | -------------------------------------------------------------------------------- /Git/27.多存储库.md: -------------------------------------------------------------------------------- 1 | # 27.多存储库 2 | 3 | 到目前为止，我们一直在使用单个 git 存储库。然而，git 擅长处理多个存储库。这些额外的存储库可以本地存储，也可以通过网络连接访问。 4 | 5 | 本节我们将创建一个名为`cloned_git_learnnig`的新存储库。展示如何从一个存储库移动更改到另一个存储库，并且当两个存储库之间发生冲突时如何处理。 6 | 7 | 目前，我们将使用本地存储库（即存储在本地硬盘上的存储库）进行工作，但是，在本节中学到的大多数内容都适用于多个存储库，无论它们是在本地还是通过网络远程存储。 8 | 9 | >注意：我们将对两个副本的仓库进行更改，操作前请确定你所在的仓库是哪个。 10 | 11 | ## 克隆 `git_learning` 仓库 12 | 13 | ```powershell 14 | # 列出当前目录下的文件及文件 15 | # 我的仓库存放在我的桌面文件夹 16 | $ ls 17 | 18 | Directory: C:\Users\aku\Desktop 19 | 20 | Mode LastWriteTime Length Name 21 | ---- ------------- ------ ---- 22 | d---- 2023/5/5 20:36 git_learning 23 | -a--- 2023/4/25 13:13 1398 Visual Studio Code.lnk 24 | 25 | # 在仓库目录的上级目录下输入 26 | $ git clone git_learning cloned_git_learnnig 27 | Cloning into 'cloned_git_learnnig'... 28 | done. 29 | ``` 30 | 31 | ## 进入 `cloned_git_learnnig` 查看提交日志 32 | 33 | ```powershell 34 | # 进入文件夹 35 | $ cd .\cloned_git_learnnig\ 36 | 37 | # 查看日志 38 | git hist 39 | * 2456c71 2023-05-05 | Added teset2.txt (HEAD -> master, origin/master, origin/lgnew, origin/HEAD) [aku] 40 | * 1c78eab 2023-05-05 | Added teset3.txt [aku] 41 | * 31e5621 2023-05-05 | Added teset2.txt [aku] 42 | * 5dc8b1e 2023-05-05 | Added .gitignore [aku] 43 | * b77158a 2023-05-05 | Moved test.txt to lab [aku] 44 | * 929f644 2023-05-05 | Added 123456 to the test.txt [aku] 45 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 46 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 47 | ``` 48 | 49 | 我们可以看到提交记录和原始仓库的提交是一样的，只是分支名称发生了改变 。 50 | 51 | ## origin 是什么？ 52 | 53 | `origin` 是 Git 默认使用的一个远程存储库的名称，当你在 Git 中克隆或创建一个新的本地存储库时，Git 默认会将其与名为 `origin` 的远程存储库相关联。 54 | 55 | ```powershell 56 | # 显示本地存储库中所有远程存储库的详细信息 57 | $ git remote 58 | origin 59 | ``` 60 | 61 | ```powershell 62 | # 查看详细信息 63 | $ git remote show origin 64 | * remote origin 65 | Fetch URL: C:/Users/aku/Desktop/git_learning 66 | Push URL: C:/Users/aku/Desktop/git_learning 67 | HEAD branch: master 68 | Remote branches: 69 | lgnew tracked 70 | master tracked 71 | Local branch configured for 'git pull': 72 | master merges with remote master 73 | Local ref configured for 'git push': 74 | master pushes to master (up to date) 75 | ``` 76 | 77 | - `remote origin`: 显示您正在查看的远程存储库的名称。 78 | - `Fetch URL`: 显示远程存储库的 URL，可以从该 URL 拉取最新代码更改。 79 | - `Push URL`: 显示可以使用的 URL 将本地更改推送到远程存储库。 80 | - `HEAD branch`: 显示在远程存储库上活动的默认分支。 81 | - `Remote branch`: 显示本地存储库中正在追踪的远程分支的列表以及其与远程分支的关系。这里的 "main tracked" 表示本地存储库中的 `main` 分支正在追踪名为 `main` 的远程分支。 82 | - `Local branch configured for 'git pull'`: 显示可以从远程存储库中拉取代码更改的本地分支以及如何与相应的远程分支合并。这里的 "main merges with remote main" 表示在运行 `git pull` 时，本地存储库中的 `main` 分支会自动与名为 `main` 的远程分支合并。 83 | - `Local ref configured for 'git push'`: 显示更新远程存储库的本地分支以及它们将被推送到远程存储库的位置。这里的 "main pushes to main (up to date)" 表示在运行 `git push` 时，本地存储库中的 `main` 分支会被推送到名为 `main` 的远程分支，并且本地分支和远程分支是同步的。 84 | 85 | ## 查看克隆仓库中的分支 86 | 87 | ```powershell 88 | # git branch 命令仅列出本地分支 89 | $ git branch 90 | * master 91 | ``` 92 | 93 | 本地分支的意思是本地仓库现有的分支。 94 | 95 | ```powershell 96 | # 查看所有分支 97 | $ git branch -a 98 | * master 99 | remotes/origin/HEAD -> origin/master 100 | remotes/origin/lgnew 101 | remotes/origin/master 102 | ``` 103 | 104 | Git 拥有原始仓库中的所有提交，但远程仓库中的分支在这里不被视为本地分支。如果我们想要自己的 `lgnew` 分支，我们需要自己创建它。 105 | -------------------------------------------------------------------------------- /Git/19.了解Git对象存储机制.md: -------------------------------------------------------------------------------- 1 | # 19.了解 Git 对象存储机制 2 | 3 | Git 使用一种称为对象存储的机制来管理和处理所有文件和目录内容，以及它们之间的关系。 4 | 5 | Git 对象存储机制包括以下几个方面： 6 | 7 | 1. Git 对象：Git 中的所有数据都被视为对象。一个对象可以是一个文件的内容（Blob）、目录结构（Tree）、提交记录（Commit）或标签（Tag）等。 8 | 2. SHA-1 哈希：每个 Git 对象都具有与其内容相关联的唯一标识符，该标识符由其内容的 SHA-1 哈希值生成。这使得 Git 可以轻松地检测文件内容的更改。 9 | 3. Git 数据库：Git 会将所有对象存储在一个数据库中，该数据库位于 `.git/objects` 目录下。该目录包含一个名为 `info` 的子目录和一个名为 `pack` 的子目录，其中 `info` 子目录包含有关对象的元数据，而 `pack` 子目录包含经过压缩的对象。 10 | 11 | ## Git 对象 12 | 13 | Git 数据库包含了许多不同类型的对象，这些对象相互关联形成一个有向无环图（DAG）。在 Git 中，每个对象都由 SHA-1 哈希值唯一标识，并按照其哈希值存储在 .git 目录下的 objects 目录中。 14 | 15 | Git 对象包括四种主要类型：blob、tree、commit 和 tag。 16 | 17 | ### Blob 18 | 19 | Blob 对象代表一个文件的内容。每个 blob 都由一个唯一的 SHA-1 哈希值标识，并存储在 .git/objects 目录下。Blob 对象是 Git 数据库的基本单位，它们包含文件的原始内容而不包含任何元数据。 20 | 21 | ### Tree 22 | 23 | Tree 对象代表一个目录或文件夹，在 Git 中被称为“树”。它可以包含多个 blob 或其他 tree 对象，以及相关元数据，如文件名和权限等信息。Tree 对象也由一个 SHA-1 哈希值唯一标识，并存储在 .git/objects 目录下的 objects/trees 子目录中。 24 | 25 | ### Commit 26 | 27 | Commit 对象代表一个 Git 提交，包含作者和提交日期等元数据，以及一个指向对应 tree 对象的指针。每个 commit 也由一个 SHA-1 哈希值唯一标识，并存储在 .git/objects 目录下。 28 | 29 | ### Tag 30 | 31 | Tag 对象代表一个 Git 标签，它可以指向特定的 commit 或其他 tag。它包含了版本号、标签类型以及描述信息等元数据，以及对应对象的 SHA-1 哈希值指针。Tag 对象也由一个 SHA-1 哈希值唯一标识，并存储在 .git/objects 目录下。 32 | 33 | 这些 Git 对象之间的关系构成了一个有向无环图（DAG），每个节点都是一个对象，每个边表示一个指针。Git 使用这种数据结构来跟踪代码库的历史记录和变化，并支持分支、合并、撤销和回滚等操作。 34 | ![1](/images/19-1有序无环图.png) 35 | 36 | ## 实验 37 | 38 | `git cat-file` 命令在 Git 中是一个非常有用的工具，特别是对于那些需要深入了解 Git 内部机制的开发人员和高级用户来说。`git cat-file` 命令通常用于以下两种情况： 39 | 40 | 1. 调试 Git 内部存储：如果您需要深入了解 Git 的内部工作方式，或者需要调试 Git 存储机制中的某些问题，则可以使用 `git cat-file` 命令查看 Git 对象的类型和内容。例如，您可以使用 `git cat-file -p ` 命令来查看一个提交对象的详细信息，包括其作者、时间、提交消息等。 41 | 2. 恢复丢失的 Git 对象：如果您的代码库中丢失了某个对象，例如 Blob 或 Tree 对象，您可以使用 `git cat-file` 命令查看该对象的 SHA-1 标识符，并尝试从其他地方恢复它。例如，您可以使用 `git cat-file -t ` 命令来验证指定的对象是否存在，如果不存在，则表示该对象已经丢失。 42 | 43 | 我们现在开始实验 44 | 45 | ### 找到最新一条提交记录 46 | 47 | ```powershell 48 | # 查看最近一条提交日志 49 | $ git hist --max-count=1 50 | * 5dc8b1e 2023-05-05 | Added .gitignore (HEAD -> master) [aku] 51 | ``` 52 | 53 | ### 查看提交对象的类型和对象的内容 54 | 55 | `-p`：查看对象内容 56 | `-t`：查看对象类型 57 | 58 | ```powershell 59 | # 查看对象类型 60 | $ git cat-file -t 5dc8b1e 61 | commit 62 | 63 | # 查看对象内容 64 | $ git cat-file -p 5dc8b1e 65 | tree 8b1db75acbd6f424e485953d3b4b8fb0de2f9065 66 | parent b77158ade22b7ec01d29dde4c2e20df0ed2008ec 67 | author aku 1683342959 -0700 68 | committer aku 1683342959 -0700 69 | 70 | Added .gitignore 71 | ``` 72 | 73 | - `Tree`：该提交所指向的树对象的 SHA-1 标识符。 74 | - `Parent`：该提交的父提交（可能有多个）的 SHA-1 标识符。 75 | - `Author`：该提交的作者姓名和电子邮件地址，以及提交时间戳。 76 | - `Committer`：该提交的提交者姓名和电子邮件地址，以及提交时间戳。 77 | - `Moved test.txt to lab`：我在提交时添加的注释。 78 | 79 | ### 探索 80 | 81 | ```powershell 82 | # 这里的哈希值，是上一步查看最新提交的 tree 哈希 83 | $ git cat-file -p 8b1db75 84 | 100644 blob cb266c781c016fa3ae0be3bab90e71145dc6b09c .gitignore 85 | 040000 tree 652058dd2d8057d2d79049dd3aa7a9f4e69d5e89 lab 86 | 87 | # 查看 lab 文件夹的哈希 88 | $ git cat-file -p 652058d 89 | 100644 blob 0605515085232c2911ca5e6c407da497c51a5c74 test.txt 90 | 91 | # 查看 test 的哈希 92 | $ git cat-file -p 060551 93 | abc 94 | 123456 95 | ``` 96 | 97 | > `100644` 是一种文件模式，也称为文件权限或 Unix 文件模式。 `6` 表示所有者可以读取和写入该文件，但不能执行。 `4` 表示组用户可以读取该文件，但不能写入或执行。 `4` 表示其他人可以读取该文件，但不能写入或执行。 98 | > 在 Unix 系统中，文件权限由一组三个数字表示，分别代表文件所有者、组用户和其他人的文件权限。每个数字表示一个具体的权限：- `0`：无权限。- `1`：执行权限。- `2`：写入权限。- `3`：写入和执行权限。- `4`：读取权限。- `5`：读取和执行权限。- `6`：读取和写入权限。- `7`：读取、写入和执行权限。 99 | > 例如上文中的 `644` 表示以下内容：文件所有者可以读写该文件（`6 = 4 + 2`）。组用户可以读该文件（`4`）。 其他人可以读该文件（`4`）。 100 | > 以下是一些常见的 Git 文件模式及其含义：- `040000`：子目录。- `120000`：符号链接。- `160000`：Git 子模块。- `33188` 或 `100644`：普通文件（文件权限为 `-rw-r--r--`）。- `33261` 或 `100755`：可执行文件（文件权限为 `-rwxr-xr-x`）。 101 | 102 | Git 对象可以帮助我们跟踪文件的历史记录和变化，并在需要时恢复旧版本的文件或比较不同版本之间的差异。在 Git 中，提交记录、树对象和文件对象都有各自的哈希值，并以这些哈希值相互关联，形成一个完整的 Git 数据库。通过使用 `git log`（[[9.设置别名]]）、`git cat-file` 等命令，我们可以查看存储库中的对象内容，并深入了解存储库的历史记录和变更。 103 | -------------------------------------------------------------------------------- /Git/17.移动文件.md: -------------------------------------------------------------------------------- 1 | # 17.移动文件 2 | 3 | 本节需要大家了解在 Git 中如何移动文件 4 | 5 | ## 第一种方式：使用 Git 命令操作 6 | 7 | 执行： 8 | | 描述 | 命令 | 9 | | -------------- | ----------- | 10 | | 创建文件夹 lab | `mkdir lab` | 11 | | 移动文件 | `git mv test.txt lab` | 12 | | 查看 Git 状态 | `git status` | 13 | | 提交 | `git commit -m "Moved test.txt to lab"` | 14 | | 查看提交历史 | `git hist` | 15 | 16 | 输出： 17 | 18 | ```powershell 19 | # 创建 lab 文件夹 20 | $ mkdir lab 21 | 22 | # 移动文件到lab目录 23 | $ git mv test.txt lab 24 | 25 | # 查看 Git 状态 26 | $ git status 27 | On branch master 28 | Changes to be committed: 29 | (use "git restore --staged ..." to unstage) 30 | renamed: test.txt -> lab/test.txt 31 | 32 | # 提交更改 33 | $ git commit -m "Moved test.txt to lab" 34 | [master 40e4259] Moved test.txt to lab 35 | 1 file changed, 0 insertions(+), 0 deletions(-) 36 | rename test.txt => lab/test.txt (100%) 37 | 38 | # 查看提交记录 39 | $ git hist 40 | * d84d6fa 2023-05-05 | Moved test.txt to lab (HEAD -> master) [aku] 41 | * 929f644 2023-05-05 | Added 123456 to the test.txt [aku] 42 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 43 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 44 | ``` 45 | 46 | ## 第二种方式：使用操作系统命令操作 47 | 48 | 我们先恢复到上一个提交状态 49 | 50 | ```powershell 51 | # 查看提交日志 52 | $ git hist 53 | * 40e4259 2023-05-05 | Moved test.txt to lab (HEAD -> master) [aku] 54 | * 929f644 2023-05-05 | Added 123456 to the test.txt [aku] 55 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 56 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 57 | 58 | # 复制移动前的提交哈希值并重置 59 | $ git reset --hard 929f644 60 | HEAD is now at 929f644 Added 123456 to the test.txt 61 | 62 | # 查看提交历史 63 | $ git hist 64 | * 929f644 2023-05-05 | Added 123456 to the test.txt (HEAD -> master) [aku] 65 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 66 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 67 | ``` 68 | 69 | 执行： 70 | | 描述 | 命令 | 71 | | -------------- | ----------------- | 72 | | 创建文件夹 lab | `mkdir lab` | 73 | | 移动文件 | `mv test.txt lab` | 74 | | 查看 Git 状态 | `git status` | 75 | | 添加到暂存区 | `git add lab` | 76 | | 删除test.txt | `git rm test.txt` | 77 | | 提交 | `git commit -m "Moved test.txt to lab"`| 78 | | 查看提交历史 | `git hist`| 79 | 80 | 输出： 81 | 82 | ```powershell 83 | # 创建 lab 文件夹 84 | $ mkdir lab 85 | 86 | # 移动文件到lab目录 87 | $ mv test.txt lab 88 | 89 | # 查看 Git 状态 90 | $ git status 91 | On branch master 92 | Changes not staged for commit: 93 | (use "git add/rm ..." to update what will be committed) 94 | deleted: test.txt 95 | Untracked files: 96 | (use "git add ..." to include in what will be committed) 97 | lab/ 98 | 99 | no changes added to commit (use "git add" and/or "git commit -a") 100 | 101 | #暂存 102 | $ git add lab 103 | 104 | # 删除文件 105 | $ git rm test.txt 106 | rm 'test.txt' 107 | 108 | # 查看 Git 状态 109 | $ git status 110 | On branch master 111 | (use "git restore --staged ..." to unstage) 112 | renamed: test.txt -> lab/test.txt 113 | 114 | # 暂存 115 | $ git add .\lab\test.txt 116 | 117 | # 提交 118 | $ git commit -m "Moved test.txt to lab" 119 | [master f40c829] Moved test.txt to lab 120 | 1 file changed, 0 insertions(+), 0 deletions(-) 121 | rename test.txt => lab/test.txt (100%) 122 | 123 | # 查看提交历史 124 | $ git hist 125 | * b77158a 2023-05-05 | Moved test.txt to lab (HEAD -> master) [aku] 126 | * 929f644 2023-05-05 | Added 123456 to the test.txt [aku] 127 | * d7f681f 2023-05-05 | Added abc to the test.txt (tag: v1) [aku] 128 | * 01b8702 2023-05-05 | Add first file (tag: v1-beta) [aku] 129 | ``` 130 | 131 | 当使用操作系统命令移动或重命名文件时，Git 无法识别这个操作，它只会看到一个文件被删除而另一个文件被创建。这意味着 Git 不知道这两个文件之间的关系，并且将新文件视为一个全新的文件。因此，在这种情况下，如果您要跟踪重命名或移动文件的历史记录，则需要手动告诉 Git 文件已经被移动。 132 | 133 | 相反，如果您使用 Git 命令来移动或重命名文件，Git 将会记录这个操作并且可以正确地跟踪文件的历史记录。具体来说，您可以使用以下 Git 命令来移动或重命名文件： 134 | 135 | - `git mv `：将源文件移动或重命名为目标文件。这会在 Git 中自动进行重命名并暂存该更改，以便在下一次提交时记录此次更改。 136 | 137 | 请注意，在执行上述 Git 命令之前，请确保先备份您的代码库，并且所有正在进行中的更改都已提交或保存。否则可能会导致数据丢失或错误的文件状态。 138 | 139 | ## 还需要注意 140 | 141 | 在 Git 中，重命名和移动文件的实现方式是相同的：Git 实际上并不对文件进行移动或重命名操作，而是将旧文件标记为已删除，并将新文件标记为新添加的文件。然后，Git 在提交历史记录中跟踪这些更改，并通过查看文件内容的相似性来确定哪些文件已被重命名或移动。 142 | 143 | ```powershell 144 | # 重命名一个文件 145 | $ git mv .\lab\test.txt .\lab\abc.txt 146 | 147 | $ git status 148 | On branch master 149 | Changes to be committed: 150 | (use "git restore --staged ..." to unstage) 151 | renamed: lab/test.txt -> lab/abc.txt 152 | 153 | # 未提交的状态下，再次执行 git mv 恢复 154 | $ git mv .\lab\abc.txt .\lab\test.txt 155 | 156 | $ git status 157 | On branch master 158 | nothing to commit, working tree clean 159 | ``` 160 | -------------------------------------------------------------------------------- /Git/04.安装Git.md: -------------------------------------------------------------------------------- 1 | # 04.安装 Git 2 | 3 | Git 安装非常简单，点击 [git-scm.com](http://git-scm.com/)，进入 Git 官网，点击 Download for Windows，点击64位Git安装程序，等待下载完毕之后，执行安装程序，默认安装即可。 4 | 5 | 等待安装完毕，在Terminal中输入 git version 命令，显示版本号，就表示已经安装成功了。 6 | 7 | 以下为Windows 安装步骤详细讲解 8 | 9 | --- 10 | 11 | ## 软件用户协议 12 | 13 | ![1](images/4-git-insall-1.png) 14 | 15 | Git 遵循 GNU 通用公共许可证，它是一种自由软件使用许可，它的存在是为了确保用户可以自由地使用、复制、修改和分发 Git 软件。通俗一点解释，你可以随便使用和修改软件，不过，你如果需要分发你的软件，也必须遵循这个许可，权利和义务对等。 16 | 17 | ## 选择软件安装路径 18 | 19 | ![2](images/4-git-insall-2.png) 20 | 21 | 安装程序在某种程度上，可以看作是一个压缩包，选择安装路径等同于选择解压路径，将安装文件释放到选择的存储位置。但实际上，安装程序比普通的压缩包要复杂得多。安装程序通常包含了一个或多个文件、配置文件、注册表项、系统服务等等。这些文件和组件需要被提取并复制到正确的位置，以便软件能够在计算机上运行。此外，安装程序还会包括其他功能，例如：创建快捷方式、注册 DLL 文件、添加环境变量等等。 22 | 23 | ## 选择需要安装的组件或功能 24 | 25 | ![3](images/4-git-insall-3.png) 26 | 27 | - 第一项， 添加桌面图标; 28 | - 第二项，添加开始菜单图标，它有两个子选项，一个是 Git Bash：这是一个在 Windows 上运行 Git 的命令行工具，提供了类似于 Unix/Linux 终端的命令行界面。另一个Git GUI：这是一个图形用户界面（GUI）工具，提供了可视化的方式来管理和操作 Git 仓库，适合那些不熟悉命令行界面的用户。 29 | - 第三项，Git LFS：这是 Git Large File Storage 的缩写，是一个用于处理大型文件的 Git 扩展，允许将大型二进制文件存储在 Git 仓库中。就比如视频音频等文件存储到 Git 仓库。 30 | - 第四项， 关联 .git 配置文件与系统的默认文本编辑器，选择这个可以用系统的默认的编辑器来编辑git的配置文件。 31 | - 第五项 将SSH配置文件关联到系统的默认命令行解释器，当选择这个选项时，Git 安装程序会尝试将 ".ssh" 文件与系统中设置的默认 bash 解释器关联起来。这样，在后续使用 Git 进行 SSH 操作时，例如生成 SSH 密钥、配置 SSH 认证等，系统会自动使用默认的 bash 解释器来执行相关的命令。 32 | - 第六项 检查更新，这个选项是指在安装 Git for Windows 过程中是否要设置每日检查 Git for Windows 更新的频率。当选择这个选项时，Git 安装程序会在每日检查是否有 Git for Windows 的更新版本可用。如果有更新版本，程序会提示用户进行更新，从而保持 Git for Windows 软件处于最新的状态，享受最新的功能和修复的 bug。 33 | - 第七项，添加git bash 配置文件到windows terminal ，之前推荐大家下载 windows terminal，这个选项默认没有勾选上，我们可以选上，选上之后会在Windows Terminal中看到 Git Bash的选项卡。 34 | - 最后一项， Scalar，Scalar 是一个 Microsoft 开发的用于改善大型 Git 仓库性能的开源工具。Scalar Git 客户端可以优化大型 Git 仓库的克隆、检出和提交等操作，从而提供更快的性能和更好的用户体验。具体实现以下功能，延迟加载，快照缓存，大文件处理，高效索引等功能。 35 | 36 | ## 选择开始菜单快捷方式创建路径 37 | 38 | ![4](images/4-git-insall-4.png) 39 | 40 | ## 选择 Git 使用的默认编辑器 41 | 42 | ![5](images/4-git-insall-5.png) 43 | 44 | 当 Git 需要使用编辑器时会调用这个选项，例如填写提交信息时。 45 | 46 | ## 主分支名称选择 47 | 48 | ![6](images/4-git-insall-6.png) 49 | 50 | - 第一项，让 Git 自行设置，默认名称 master。 51 | - 第二项是自定义，在Git 2.28版本之后，Git的默认主分支名称从 "master" 更改为 "main"。这里我先给大家解释一下分支的意思，假如我们需要写一个文档，当写着写着，发现还有不同的写法，这时候，我们把这个文件重新复制一份，开始编写，这里最开始写的文档，可以理解为主分支，我们复制后开始写的另一份，就是原始文档的分支。分支名称用于区分不同版本以及不同功能，控制版本。 52 | 53 | ## 添加环境变量 54 | 55 | ![7](images/4-git-insall-7.png) 56 | 57 | - 第一项，只有Git Bash 能运行Git， 58 | 59 | - 第二项，命令行(CMD或者 PowerShell)和第三方软件也可以运行 Git； 60 | - 第三项，选择这个选项时，Git 安装程序将会安装一些类似于 Unix 工具的软件，例如 curl、grep、awk、sed 等。这些工具可以在 Git Bash 环境中使用，提供了类似于 Unix/Linux 系统中的命令行工具，使您能够在 Windows 系统中执行一些类似于 Unix/Linux 环境下的操作。 61 | 62 | 我再解释一下环境变量，环境变量是系统或用户定义的特殊变量，用来存储一些运行环境相关的信息。这些信息通常包含了一些路径、配置参数、编译器选项等，可供不同程序和进程使用。就以 Git 为例，默认选项会将 Git 的可执行程序目录添加到 PATH 中，这样我就可以在终端中调用 Git 所有的程序。 63 | 64 | ## 选择 SSH 可执行程序 65 | 66 | ![8](images/4-git-insall-8.png) 67 | 68 | SSH（Secure Shell）是一种网络协议，用于在不安全的网络中进行安全的远程访问和数据传输。第一项是Git已经集成的OpenSSH客户端程序，第二个选择系统已安装的SSH程序，常见的SSH客户端程序有 OpenSSH、PuTTY、SecureCRT等。在计算机领域中，不安全的网络通常指的是公共网络，例如互联网、无线局域网（WLAN）、蓝牙等。这些网络连接涵盖了广泛的用户和设备，并且往往没有进行足够的安全保护措施，容易被黑客或攻击者利用进行数据窃取、篡改或破坏。 69 | 70 | ## 选择 HTTPS 协议后端库 71 | 72 | ![9](images/4-git-insall-9.png) 73 | 74 | HTTPS（Hypertext Transfer Protocol Secure）是一种通过加密和认证的方式，使数据在网络传输过程中更加安全的通信协议。使用 HTTPS 进行 Git 仓库的访问可以提供更高的安全性，因为数据在传输过程中会被加密，防止中间人攻击和数据泄露。 75 | 76 | 当使用 "HTTPS" 作为 Git 的远程仓库访问方式时，通常需要提供远程仓库的 HTTPS URL，以及相应的用户名和密码（或者访问令牌）进行认证。这样在执行 Git 操作时，如克隆、推送、拉取等，Git 会通过 HTTPS 协议进行安全的数据传输和认证。选择 "HTTPS" 通常比较简单和方便，因为无需配置 SSH 密钥，适合那些不熟悉 SSH 密钥管理或不具备 SSH 服务器权限的情况。 77 | 78 | "OpenSSL Library" 是一个开源的加密库，提供了多种加密和安全功能，包括 SSL/TLS 协议的实现。Git 可以使用 OpenSSL Library 作为其 HTTPS 通信的加密库，通过 HTTPS 协议进行安全的数据传输和认证。 79 | 80 | "Native Windows Secure Channel library" 是 Windows 操作系统自带的安全通信库，用于实现安全通信协议，协议里包括 HTTPS。Git 可以使用 Windows 自带的 Secure Channel library 进行 HTTPS 通信。 81 | 82 | 这两个选项之间的选择通常取决于个人的偏好和需求。"OpenSSL Library" 是一个跨平台的开源库，适用于多种操作系统，而 "Native Windows Secure Channel library" 是 Windows 平台自带的库，可能对于在 Windows 环境下使用 Git，更加方便，集成度更高。选择哪个选项取决于用户的操作系统和安全需求。 83 | 84 | ## 操作系统文本文件行尾转换方式选择 85 | 86 | ![10](images/4-git-insall-10.png) 87 | 88 | 在 Windows、Linux 和 macOS 等操作系统中，文本文件的行尾表示方式不同。Windows 使用 CRLF（回车换行）作为接尾，Linux 和 macOS 使用 LF（换行）作为结尾。这可能会导致在不同操作系统之间的文本文件在 Git 版本控制中出现行尾不一致的问题。 89 | 90 | - 第一项，在检出文件时将行尾转换为 Windows 样式（CRLF），在提交文件时将行尾转换为 Unix 样式（LF）。适用于在 Windows 系统上开发但需要与 Linux 或 macOS 系统共享代码的项目。 91 | 92 | - 第二项，不进行行尾转换，文件将按照原样从版本库检出，并在提交文件时转换为 Unix 样式（LF）。适用于在 Linux 或 macOS 系统上开发并与其他相同系统的项目共享代码。 93 | 94 | 第三项，不进行行尾转换，文件将按照原样从版本库检出并提交。适用于不需要处理行尾转换的项目。 95 | 96 | ## 设置Git Bash的终端模拟器 97 | 98 | ![11](images/4-git-insall-11.png) 99 | 100 | Git Bash 是一个在 Windows 系统上运行的命令行界面，它模拟了类似于 Linux 或 macOS 终端的功能，并提供了 Git 工具的命令行接口。终端模拟器是一种软件，用于模拟命令行界面，允许用户在图形化界面中输入和执行命令。 101 | 102 | - 第一项，使用安装程序自带的终端Mintty , Mintty是一个基于 Cygwin 和 MSYS2 的终端模拟器，用于在 Windows 系统上运行类 Unix 环境下的命令行工具。它是 Git for Windows（也称为 Git Bash）默认使用的终端模拟器之一。 103 | 104 | - 第二项，使用 Windows 默认的控制台窗口作为 Git Bash 的终端模拟器，例如 CMD 或者 PowerShell 命令行窗口 105 | 106 | ## 选择拉取远程仓库的默认方式 107 | 108 | ![12](images/4-git-insall-12.png) 109 | 110 | git pull 命令用于从远程仓库拉取代码并合并到当前分支。`git pull` 命令在默认情况下使用快速（fast-forward） 模式进行合并（merge）操作。这意味着如果当前分支是基于目标分支的直接上游分支（没有其他分支在其之间），也就是各个提交是线性的，中间没有其它分支混合。那么 **`git pull`** 命令会简单地将目标分支的提交合并到当前分支，从而快速前进（fast-forward）当前分支。 111 | 112 | 使用 fast-forward 合并模式的优点是合并历史简洁且线性，适用于在进行日常开发时，保持提交历史的整洁性和简单性。它适用于以下情况： 113 | 114 | 1. 当目标分支是当前分支的直接上游分支，且没有其他分支在其之间。 115 | 2. 当多个开发者在同一时间在不同的分支上进行独立的开发，并且没有冲突需要解决。 116 | 3. 当只需要将目标分支的提交合并到当前分支，并且不需要对提交历史进行复杂的修改。 117 | 118 | 另一方面，**`git pull`** 命令也可以使用合并（merge）模式进行合并操作，该模式会创建一个新的合并提交，包含了从目标分支合并到当前分支的所有提交，从而形成一个分支合并的提交历史。这种方式可能会导致提交历史较为复杂，包含了多个合并提交，不过在某些情况下可能是必要的，例如在解决合并冲突时或者需要保留详细的合并历史时。 119 | 120 | 在选择 **`git pull`** 命令的合并模式时，应根据具体的情况和团队的合作流程进行选择。如果希望保持提交历史简洁和线性，可以选择 fast-forward 模式。如果需要更详细的合并历史或者需要解决合并冲突时，可以选择合并模式。 121 | 122 | 第二项，选用rebase（覆盖） ，当使用 **`rebase`** 模式进行 **`git pull`** 操作时，Git 会尝试将当前分支的提交重新应用在目标分支的最新提交之上，而不是简单地创建一个新的合并提交。 123 | 124 | 使用 **`rebase`** 模式的主要优点是可以在提交历史中创建一个干净的、线性的合并历史，从而避免了创建多个合并提交的情况。这有助于保持提交历史的简洁性和可读性，减少了合并提交可能导致的提交历史混乱。 125 | 126 | **`rebase`** 模式通常适用于以下情况： 127 | 128 | 1. 当目标分支有较新的提交，并且希望将当前分支的提交应用在最新的目标分支之上，以便保持提交历史的整洁性。 129 | 2. 当在进行多人协作开发时，希望将当前分支的提交整合到目标分支的最新提交之上，而不是创建多个合并提交。 130 | 3. 当需要对当前分支的提交进行覆盖（rebase）操作，以便合并到目标分支后的提交历史更加整洁和有序。 131 | 132 | 需要注意的是，使用 **`rebase`** 模式进行 **`git pull`** 操作可能会导致提交历史的改变，因为它会重新应用提交。因此，在选择使用 **`rebase`** 模式时，应谨慎处理可能涉及到的提交历史变更，并在团队中明确定义和遵循合作流程。 133 | 134 | 第三项 only ever fast-forward 模式 135 | 136 | 选择 "only ever fast-forward" 选项意味着在执行 **`git pull`** 操作时，Git 会尝试使用 "fast-forward" 方式进行合并，只有在当前分支的提交可以直接在目标分支的最新提交之上移动时才会执行合并。 137 | 138 | "Fast-forward" 合并是一种简单的合并方式，它只是将当前分支的指针直接移动到目标分支的最新提交，从而使当前分支的提交历史保持线性，并且没有额外的合并提交。 139 | 140 | 选择 "only ever fast-forward" 选项适用于以下情况： 141 | 142 | 1. 当希望保持提交历史的线性，避免创建额外的合并提交。 143 | 2. 当确认当前分支的提交可以直接在目标分支的最新提交之上移动，并且不会导致合并冲突时。 144 | 145 | 需要注意的是，选择 "only ever fast-forward" 选项可能会导致 **`git pull`** 操作失败，如果当前分支的提交无法直接在目标分支的最新提交之上移动，例如存在合并冲突的情况。在选择该选项时，应确保当前分支的提交与目标分支的提交是兼容的，并且可以直接合并，以避免潜在的合并冲突。 146 | 147 | ## 选择个人凭据认证辅助工具 148 | 149 | ![13](images/4-git-insall-13.png) 150 | 151 | 凭据辅助工具用于在执行 Git 操作时处理认证信息，例如用户名和密码，以便自动化地进行身份验证，而无需手动输入认证信息。 152 | 153 | 第一项，Git Credential Manager， 它可以帮助管理和存储 Git 认证信息，并在需要时自动提供认证信息。 154 | 155 | 第二项，None，不需要任何凭据辅助工具，每次需要认证时都需要手动输入用户名和密码。 156 | 157 | ## 额外选项 158 | 159 | ![14](images/4-git-insall-14.png) 160 | 161 | 第一项文件缓存，文件系统缓存是一种优化技术，它可以在某些情况下显著提高 Git 的性能。当启用文件系统缓存时，Git 会将一些常用的元数据信息（例如文件状态、文件索引等）缓存到内存中，从而减少对硬盘的读写操作，从而提高 Git 命令的执行速度。 162 | 163 | 启用文件系统缓存可以在某些场景下对 Git 命令的执行速度带来显著的提升，例如在大型仓库或者频繁执行 Git 命令的情况下。然而，对于小型仓库或者不频繁执行 Git 命令的情况，文件系统缓存可能不会带来明显的性能提升。 164 | 165 | 需要注意的是，启用文件系统缓存可能会增加一些系统资源的消耗，例如内存和 CPU 使用率。因此，在选择是否启用文件系统缓存时，需要综合考虑你的系统配置和使用情况，权衡性能提升和资源消耗之间的关系。如果你对文件系统缓存不了解或者不确定是否需要启用，建议使用 Git 的默认配置，即不启用文件系统缓存。 166 | 167 | 第二项，软链接或者符号，它用于配置 Git 是否允许使用符号链接（symbolic links），软链接是一种创建一个指向另一个文件或目录的特殊类型文件的链接，类似于快捷方式。 168 | 169 | 启用符号链接选项意味着 Git 将允许在仓库中创建、使用和管理符号链接。这可以在某些情况下对 Git 仓库的管理和使用带来便利，例如在需要共享文件或目录时，避免重复复制文件的开销，或者在跨不同操作系统的环境中使用 Git 时需要处理符号链接。 170 | 171 | 需要注意的是，启用符号链接选项可能会涉及一些系统权限和兼容性方面的考虑。例如，在某些操作系统或文件系统上，创建和使用符号链接可能需要管理员权限或者特定的文件系统支持。因此，在选择是否启用符号链接选项时，需要考虑你的系统环境和使用需求，并确保了解符号链接的工作原理和限制。如果不了解或者不需要使用符号链接，建议使用 Git 的默认配置，即不启用符号链接。 172 | 173 | ## 实验选项 174 | 175 | ![15](images/4-git-insall-15.png) 176 | 177 | 第一项伪控制台支持，伪控制台是一种在 Windows 系统上运行命令行应用程序时模拟的控制台环境，用于支持一些高级的终端特性，例如 ANSI 转义序列、颜色和光标控制等。 178 | 179 | 第二项，文件监控，用于启用内置的文件系统监视器。这个监视器可以在 Git 仓库中检测文件系统的变化，并在文件发生变化时自动更新 Git 的文件状态信息。 180 | 181 | 启用这个选项后，Git 将会监视仓库所在文件系统的文件和目录的变化，例如文件的创建、修改、删除等操作，并自动更新 Git 的文件状态信息，使得 Git 可以更准确地反映文件系统的最新状态。这可以帮助 Git 在处理文件状态变更时更加及时地更新仓库的状态，从而提高工作效率。 182 | 183 | 然而，需要注意的是，这个选项可能会对系统资源产生一定的影响，因为文件系统监视需要不断地检测文件系统的变化。在大型仓库或者文件系统变更频繁的情况下，启用这个选项可能会导致 Git 进程的资源占用较高。因此，在启用这个选项时，需要根据具体情况评估系统资源的使用情况，并根据实际需求来做出决策。 184 | 185 | 如果不需要实时监视文件系统的变化，或者对系统资源有限的情况下，也可以选择禁用这个选项，手动使用 Git 的命令来更新文件状态信息，如 `git status`、`git add`、`git rm` 等。 186 | --------------------------------------------------------------------------------