Git：入门
This commit is contained in:
parent
f05b93e8c3
commit
ea75dec9ce
8
wiki/dev/Git/入门/_category_.json
Normal file
8
wiki/dev/Git/入门/_category_.json
Normal file
@ -0,0 +1,8 @@
|
||||
{
|
||||
"label": "入门",
|
||||
"position": 1,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"title": "入门"
|
||||
}
|
||||
}
|
||||
@ -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 命令。
|
||||
|
||||
@ -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 都是很棒的开源社区。
|
||||
@ -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
|
||||
@ -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 配置
|
||||
|
||||
Loading…
Reference in New Issue
Block a user