From ea75dec9ce97537d4593243ce9f8438597e43302 Mon Sep 17 00:00:00 2001 From: 7Wate Date: Tue, 13 Sep 2022 16:04:55 +0800 Subject: [PATCH] =?UTF-8?q?Git=EF=BC=9A=E5=85=A5=E9=97=A8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- wiki/dev/Git/入门/_category_.json | 8 ++++ wiki/dev/Git/{ => 入门}/分支.md | 22 +++++++---- wiki/dev/Git/{服务.md => 入门/协议.md} | 19 ++++++---- wiki/dev/Git/{ => 入门}/基础.md | 30 ++++++++++----- wiki/dev/Git/{ => 入门}/起步.md | 52 ++++++++++++++------------ 5 files changed, 82 insertions(+), 49 deletions(-) create mode 100644 wiki/dev/Git/入门/_category_.json rename wiki/dev/Git/{ => 入门}/分支.md (97%) rename wiki/dev/Git/{服务.md => 入门/协议.md} (97%) rename wiki/dev/Git/{ => 入门}/基础.md (89%) rename wiki/dev/Git/{ => 入门}/起步.md (61%) diff --git a/wiki/dev/Git/入门/_category_.json b/wiki/dev/Git/入门/_category_.json new file mode 100644 index 00000000..899087c7 --- /dev/null +++ b/wiki/dev/Git/入门/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "入门", + "position": 1, + "link": { + "type": "generated-index", + "title": "入门" + } +} \ No newline at end of file diff --git a/wiki/dev/Git/分支.md b/wiki/dev/Git/入门/分支.md similarity index 97% rename from wiki/dev/Git/分支.md rename to wiki/dev/Git/入门/分支.md index da595a87..28e51445 100644 --- a/wiki/dev/Git/分支.md +++ b/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 这会在当前所在的提交对象上创建一个指针。 -### 分支切换 +### 切换分支 要切换到一个已存在的分支，你需要使用 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 / git branch -vv ``` -### 拉取 +### 拉取分支 当从服务器上抓取本地没有的数据时，可以运行 git fetch 或 git pull。推荐单独显式地使用 fetch 与 merge 命令。 diff --git a/wiki/dev/Git/服务.md b/wiki/dev/Git/入门/协议.md similarity index 97% rename from wiki/dev/Git/服务.md rename to wiki/dev/Git/入门/协议.md index 5f3e6154..f3e9d92f 100644 --- a/wiki/dev/Git/服务.md +++ b/wiki/dev/Git/入门/协议.md @@ -1,13 +1,16 @@ --- -id: 服务 -title: 服务 -sidebar_position: 5 -data: 2022年1月13日 +title: 协议 +description: Git 常见协议 +keywords: +- 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 都是很棒的开源社区。 diff --git a/wiki/dev/Git/基础.md b/wiki/dev/Git/入门/基础.md similarity index 89% rename from wiki/dev/Git/基础.md rename to wiki/dev/Git/入门/基础.md index e1ce3a2a..29bf1312 100644 --- a/wiki/dev/Git/基础.md +++ b/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 git clone ``` -克隆现有的仓库，实际上是多个命令的分解。首先初始化一个本地仓库，接着添加远程仓库，最后拉取远程仓库数据到本地。 +克隆现有的仓库，实际上是**多个命令的分解**。首先初始化一个本地仓库，接着添加远程仓库，最后拉取远程仓库数据到本地。 ## 记录每次更新到仓库 @@ -56,9 +64,11 @@ git clone ### 忽略文件 -有些文件无需纳入 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 -- ### 查看远程仓库 -可以运行 git remote 命令，查看你已经配置的远程仓库服务器。 +运行 git remote 命令，查看你已经配置的远程仓库服务器。 ```shell // 查看远程仓库 git remote ``` -你也可以指定选项 -v，会显示需要读写远程仓库使用的 Git 保存的简写与其对应的 URL +也可以指定选项 -v，会显示需要读写远程仓库使用的 Git 保存的简写与其对应的 URL ```shell // 显示远程仓库简写及其 URL diff --git a/wiki/dev/Git/起步.md b/wiki/dev/Git/入门/起步.md similarity index 61% rename from wiki/dev/Git/起步.md rename to wiki/dev/Git/入门/起步.md index ac3a7141..15cdf500 100644 --- a/wiki/dev/Git/起步.md +++ b/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. 在工作区中修改文件（**已修改**）。 -2. 将你下次想要提交的更改选择性地暂存，这样只会将更改的部分添加到暂存区（**已暂存**）。 -3. 提交更新，找到暂存区的文件，将快照永久性存储到 Git 目录（**已提交**）。 +1. 在**工作区**中修改文件（**已修改**）。 +2. 将你下次想要提交的更改选择性地暂存，这样只会将更改的部分**添加到暂存区**（**已暂存**）。 +3. 提交更新，找到暂存区的文件，将快照**永久性存储到 Git 目录**（**已提交**）。 -## 首次运行 Git +## Git 首次运行 -安装 Git 后要先定制你的 Git 环境，仅需配置一次，升级时保留配置信息。 +Git 安装后首先要定制环境，仅需**配置一次，升级时保留配置**信息。 ### Git 配置