Git：入门

wiki/dev/Git/入门/_category_.json

@@ -0,0 +1,8 @@
+{
+    "label": "入门",
+    "position": 1,
+    "link": {
+      "type": "generated-index",
+      "title": "入门"
+    }
+}

wiki/dev/Git/入门/分支.md

@@ -1,13 +1,19 @@
 ---
-id: 分支
 title: 分支
+description: Git 分支操作
+keywords:
+- Git
+- 分支
+tags:
+- Git
 sidebar_position: 3
-data: 2022年1月13日
+author: 7Wate
+date: 2022-09-13
 ---
 
-Git 的分支模型被称为它的「必杀技特性」，也正因为这一特性，使得 Git 从众多版本控制系统中脱颖而出。
+Git 的分支模型被称为它的**「必杀技特性」**，也正因为这一特性，使得 Git 从众多版本控制系统中脱颖而出。
 
-## 分支简介
+## 分支操作
 
 因为 Git 保存的不是文件的变化或者差异，而是一系列不同时刻的 快照 。
 
@@ -24,7 +30,7 @@ git branch <branch-name>
 
 这会在当前所在的提交对象上创建一个指针。
 
-### 分支切换
+### 切换分支
 
 要切换到一个已存在的分支，你需要使用 git checkout 命令。
 
@@ -97,7 +103,7 @@ git checkout master
 git checkout -b hotfix
 ```
 
-### 分支的合并
+### 合并分支
 
 然后将 hotfix 分支合并回你的 master 分支来部署线上。
 
@@ -127,7 +133,7 @@ git merge iss53
 
 在这种情况下，你的开发历史从一个更早的地方开始分叉开来（diverged）。 因为，master 分支所在提交并不是 iss53 分支所在提交的直接祖先，Git 不得不做一些额外的工作。 出现这种情况的时候，Git 会使用两个分支的末端所指的快照以及这两个分支的公共祖先，做一个简单的三方合并。
 
-### 遇到冲突时的分支合并
+### 冲突时的分支合并
 
 有时候合并操作并不会如此顺利，因为如果涉及到同一个文件的同一处，就会在合并时产生冲突。此时 Git 做了合并，但是没有自动地创建一个新的合并提交。 Git 会暂停下来，等待你去解决合并产生的冲突。
 
@@ -193,7 +199,7 @@ git branch -u <remote>/<branch>
 git branch -vv
 ```
 
-### 拉取
+### 拉取分支
 
 当从服务器上抓取本地没有的数据时，可以运行 git fetch 或 git pull。推荐单独显式地使用 fetch 与 merge 命令。
 

wiki/dev/Git/入门/协议.md

@@ -1,13 +1,16 @@
 ---
-id: 服务
+title: 协议
-title: 服务
+description: Git 常见协议
-sidebar_position: 5
+keywords:
-data: 2022年1月13日
+- Git
+- 协议
+tags:
+- Git
+sidebar_position: 4
+author: 7Wate
+data: 2022年9月13日
 ---
 
-
-
-
 到目前为止，你应该已经有办法使用 Git 来完成日常工作。 然而，为了使用 Git 协作功能，你还需要有远程的 Git 仓库。 尽管在技术上你可以从个人仓库进行推送（push）和拉取（pull）来修改内容，但不鼓励使用这种方法，因为一不留心就很容易弄混其他人的进度。 此外，你希望你的合作者们即使在你的电脑未联机时亦能存取仓库 — 拥有一个更可靠的公用仓库十分有用。 因此，与他人合作的最佳方法即是建立一个你与合作者们都有权利访问，且可从那里推送和拉取资料的共用仓库。
 
 架设一台 Git 服务器并不难。如果你不介意托管你的代码在其他人的服务器，且不想经历设置与维护自己服务器的麻烦，可以试试第三方仓库托管服务。
@@ -84,4 +87,4 @@ Git 协议缺点是缺乏授权机制。 把 Git 协议作为访问项目版本
 
 ## 第三方托管
 
-现在已经拥有了很多更现代，功能更全的 Git 服务器，GitLab 便是其中最出名的一个，同时 GitHub、Gitte 都是很棒的开源社区。
+现在已经拥有了很多更现代，功能更全的 Git 服务器，GitHub 便是其中最出名的一个，同时 GitLab、Gitee 都是很棒的开源社区。

wiki/dev/Git/入门/基础.md

@@ -1,11 +1,19 @@
 ---
-id: 基础
 title: 基础
+description: Git 基础操作
+keywords:
+- Git
+- 基础
+tags:
+- Git
 sidebar_position: 2
-data: 2022年1月13日
+author: 7Wate
+date: 2022-09-13
 ---
 
-如果你只想通过阅读一章来学习 Git，那么本章将是你的不二选择。 本章涵盖了你在使用 Git完成各种工作时将会用到的各种基本命令。 在学习完本章之后，你应该能够配置并初始化一个仓库（repository）、开始或停止跟踪（track）文件、暂存（stage）或提交（commit）更改。 本章也将向你演示了如何配置 Git 来忽略指定的文件和文件模式、如何迅速而简单地撤销错误操作、如何浏览你的项目的历史版本以及不同提交（commits）之间的差异、如何向你的远程仓库推送（push）以及如何从你的远程仓库拉取（pull）文件。
+本章涵盖了你在使用 Git完成各种工作时将会用到的各种基本命令。 在学习完本章之后，你应该能够配置并初始化一个仓库（repository）、开始或停止跟踪（track）文件、暂存（stage）或提交（commit）更改。 
+
+本章也将向你演示了如何配置 Git 来忽略指定的文件和文件模式、如何迅速而简单地撤销错误操作、如何浏览你的项目的历史版本以及不同提交（commits）之间的差异、如何向你的远程仓库推送（push）以及如何从你的远程仓库拉取（pull）文件。
 
 ## 获取 Git 仓库
 
@@ -17,7 +25,7 @@ data: 2022年1月13日
 ### 在目录中初始化仓库
 
 ```shell
-// 在当前目录初始化仓库
+// 当前目录下初始化仓库
 git init
 ```
 
@@ -39,7 +47,7 @@ git clone <url>
 git clone <url> <name>
 ```
 
-克隆现有的仓库，实际上是多个命令的分解。首先初始化一个本地仓库，接着添加远程仓库，最后拉取远程仓库数据到本地。
+克隆现有的仓库，实际上是**多个命令的分解**。首先初始化一个本地仓库，接着添加远程仓库，最后拉取远程仓库数据到本地。
 
 ## 记录每次更新到仓库
 
@@ -56,9 +64,11 @@ git clone <url> <name>
 
 ### 忽略文件
 
-有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。在这种情况下，我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件的模式。不同目录下可以拥有不同的 .gitignore 。
+有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。
 
-文件 .gitignore 的格式规范如下：
+在这种情况下，我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件的模式，不同目录下可以拥有不同的 .gitignore 。
+
+#### .gitignore 格式规范：
 
 - 所有空行或者以 # 开头的行都会被 Git 忽略。
 - 可以使用标准的 glob 模式匹配，它会递归地应用在整个工作区中（glob 模式是指 shell 所使用的简化了的正则表达式）。
@@ -156,7 +166,7 @@ git log --pretty=format:"%h - %an, %ar : %s"
 | %cr  | 提交日期（距今多长时间）                      |
 | %s   | 提交说明                                      |
 
-### 限制 git log 输出的选项
+### git log 限制输出的选项
 
 | 选项              | 说明                                       |
 | ----------------- | ------------------------------------------ |
@@ -207,14 +217,14 @@ git checkout -- <file>
 
 ### 查看远程仓库
 
-可以运行 git remote 命令，查看你已经配置的远程仓库服务器。
+运行 git remote 命令，查看你已经配置的远程仓库服务器。
 
 ```shell
 // 查看远程仓库
 git remote
 ```
 
-你也可以指定选项 -v，会显示需要读写远程仓库使用的 Git 保存的简写与其对应的 URL
+也可以指定选项 -v，会显示需要读写远程仓库使用的 Git 保存的简写与其对应的 URL
 
 ```shell
 // 显示远程仓库简写及其 URL

wiki/dev/Git/入门/起步.md

@@ -1,15 +1,21 @@
 ---
-id: 起步
 title: 起步
+description: Git 起步
+keywords:
+- Git
+- 起步
+tags:
+- Git
 sidebar_position: 1
-data: 2022年1月13日
+author: 7Wate
+date: 2022-09-13
 ---
 
-本章介绍开始使用 Git 前的相关知识。我们会先了解一些版本控制工具的历史背景，然后试着让 Git 在你的系统上跑起来，直到最后配置好，可以正常开始开发工作。读完本章，你就会明白为什么 Git 会如此流行，为什么你应该立即开始使用它。
+我们会先了解一些版本控制工具的历史背景，然后试着让 Git 在你的系统上跑起来，直到最后配置好，可以正常开始开发工作。读完本章，你就会明白为什么 Git 会如此流行，为什么你应该立即开始使用它。
 
 ## 版本控制系统
 
-版本控制系统（Version Control Systems，简称 VCS）是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。
+版本控制系统（Version Control Systems，VCS）是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。
 
 ### 本地版本控制系统
 
@@ -19,15 +25,15 @@ data: 2022年1月13日
 
 ### 集中化的版本控制系统
 
-为了解决本地版本控制系统无法协同工作的问题，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应允而生。其采用一个单一集中管理的服务器，保存所有文件的修订版本；协作者通过客户端连接服务器，拉取最新文件或提交更新。
+为了解决本地版本控制系统无法协同工作的问题，集中化的版本控制系统（Centralized Version Control Systems，CVCS）应允而生。其采用一个单一集中管理的服务器，保存所有文件的修订版本；协作者通过客户端连接服务器，拉取最新文件或提交更新。
 
-**优点**：相较于本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
+ - **优点**：相较于本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
 
-**缺点**：显而易见的缺点是中央服务器的单点故障。例如宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作；如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。
+ - **缺点**：显而易见的缺点是中央服务器的单点故障。例如宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作；如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。
 
 ### 分布式版本控制系统
 
-为了解决集中化的版本控制系统的痛处，分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。分布式顾名思义，每一个节点都基于公认中心节点服务器的镜像拷贝，故每个节点都拥有代码仓库的完整信息。因此不存在中心节点故障无法工作、物理损坏无法恢复、日志历史不完整导致协作者无法相互协作。
+为了解决集中化的版本控制系统的痛处，分布式版本控制系统（Distributed Version Control System，DVCS）面世了。分布式顾名思义，每一个节点都基于公认中心节点服务器的镜像拷贝，故每个节点都拥有代码仓库的完整信息。因此不存在中心节点故障无法工作、物理损坏无法恢复、日志历史不完整导致协作者无法相互协作。
 
 更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。
 
@@ -35,7 +41,7 @@ data: 2022年1月13日
 
 同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。
 
-Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。
+Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002 年间）。到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。
 
 到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用BitKeeper 时的经验教训，开发出自己的版本系统。 他们对新的系统制订了若干目标：
 
@@ -59,7 +65,7 @@ Git 与其他版本控制系统主要差别在于对待数据的方法；**Git
 
 由于 Git 是分布式版本控制系统，在不对公认中心节点服务器操作的情况下，绝大多数操作都只需要访问本地文件资源。故 Git 大部分操作看起来瞬间完成，不存在网络延时。
 
-### Git 保证数据完整性
+### 保证数据完整性
 
 Git 中所有的数据在存储前都用 SHA-1 散列（hash，哈希）计算校验和并以哈希值来索引，而不是文件名。这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。
 
@@ -68,33 +74,33 @@ Git 中所有的数据在存储前都用 SHA-1 散列（hash，哈希）计算
 24b9da6552252987aa493b52f8696cd6d3b00373
 ```
 
-### Git 一般只添加数据
+### 一般只添加数据
 
 因为 Git 一般只添加数据，所以你很难让 Git 执行任何不可逆操作，或者让它以任何方式清除数据。
 
 ### Git 的三种状态
 
-Git 有三种状态，你的文件可能处于其中之一： **已提交（committed）**、**已修改（modified）** 和 **已暂存（staged）**。
+Git 有三种状态，你的文件可能处于其中之一： **已修改（modified）** 、**已暂存（staged）**和**已提交（committed）**。
 
-- 已修改表示修改了文件，但还没保存到数据库中
+- 已修改：修改了文件，但还没保存到数据库中
-- 已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。
+- 已暂存：对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。
-- 已提交表示数据已经安全地保存在本地数据库中。
+- 已提交：数据已经安全地保存在本地数据库中。
 
 这会让我们的 Git 项目拥有三个阶段：**工作区（Working Directory）**、**暂存区（Staging Area）** 以及 **Git 目录（Repository）**。
 
-- 工作区对项目的某个版本独立提取出来的内容，放在磁盘上供你使用或修改。
+- 工作区：工作区对项目的某个版本独立提取出来的内容，放在磁盘上供你使用或修改。
-- 暂存区（术语：索引）保存了下次将要提交的文件列表信息。
+- 暂存区：保存了下次将要提交的文件列表信息。
-- Git 目录是 Git 用来保存项目的元数据和对象数据库的地方。
+- Git 目录：Git 用来保存项目的元数据和对象数据库的地方。
 
 所以 Git 的基本工作流程如下：
 
-1. 在工作区中修改文件（**已修改**）。
+1. 在**工作区**中修改文件（**已修改**）。
-2. 将你下次想要提交的更改选择性地暂存，这样只会将更改的部分添加到暂存区（**已暂存**）。
+2. 将你下次想要提交的更改选择性地暂存，这样只会将更改的部分**添加到暂存区**（**已暂存**）。
-3. 提交更新，找到暂存区的文件，将快照永久性存储到 Git 目录（**已提交**）。
+3. 提交更新，找到暂存区的文件，将快照**永久性存储到 Git 目录**（**已提交**）。
 
-## 首次运行 Git
+## Git 首次运行
 
-安装 Git 后要先定制你的 Git 环境，仅需配置一次，升级时保留配置信息。
+Git 安装后首先要定制环境，仅需**配置一次，升级时保留配置**信息。
 
 ### Git 配置