90DaysOfDevOps 中文版：安装与配置 Git（Day 36）——从 Windows/Linux 安装到 .gitconfig 全局配置与分布式版本控制原理-育师

文档/教程

【免费下载链接】90DaysOfDevOps

This repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.

项目地址：https://gitcode.com/gh_mirrors/90/90DaysOfDevOps

点击查看免费下载

Git 是一个开源、跨平台的版本控制工具，也是 90DaysOfDevOps 挑战路线中进入代码版本管理实践的关键一步。本篇指南围绕 2022/zh_cn/Days/day36.md 展开，完整覆盖 Git 在 Windows 与 Linux/Ubuntu 上的安装与升级流程、安装向导中关键选项（Git Bash、SSH Executable、实验性功能）的取舍、首次使用必备的全局配置（用户名、邮箱、默认编辑器、换行符），并深入对比"客户端-服务器"与"分布式"两种版本控制模型的区别。读完本文，你将能够在自己的开发机上从零装好最新版 Git，通过三个配置层级（System/Global/Local）完成个性化设置，并理解 Git 之所以成为分布式版本控制事实标准的底层原因，为后续了解 Git 常用命令（Day 37）打下基础。

一、为什么需要安装与配置 Git

Git 是开源、跨平台的版本控制工具。如果你使用 Ubuntu 或其他 Linux 发行版，系统可能已经预装了 Git——正如本仓库的文档环境那样。但无论是否已经安装，都建议先确认版本，并尽量保持为最新版本：较新版本通常会带来更快的性能、更完善的安全修复（包括针对恶意仓库的防护补丁）以及更好的协议支持。

所以本节的目标很简单：

检查当前系统已安装的 Git 版本；
如果版本过旧或尚未安装，通过官方渠道安装最新版；
完成身份与编辑器的首次配置，保证后续每次提交（commit）都能记录正确的作者信息。

二、安装 Git：Windows 与 Linux 双平台实操

Git 是跨平台的，支持 Windows、Linux 和 macOS。Windows 用户可以从官网下载官方安装包；macOS 的安装方式在 Git 官方《起步-安装 Git》章节中有说明。在 Windows 上，除了图形安装包，还可以使用winget——可以把它理解成 Windows 的应用程序包管理器，用命令行即可完成安装。

2.1 安装前的版本检查

在安装任何东西之前，先确认当前机器上的 Git 版本。打开 PowerShell 窗口，运行：

git --version

例如在作者的 Windows 机器上，检查结果显示的是git version 2.31.1.windows.1，而本文撰写时 Windows 的最新发布版本为2.35.1，因此需要更新。同样的，也可以在 WSL Ubuntu 中执行git --version检查 Linux 侧的版本，通常也会发现有所滞后，需要走一遍更新流程。

注意：文档中的版本号2.35.1是撰写当时的快照，实际安装时请以官网当前发布的最新稳定版为准；下述流程对任意较新版本均适用。

2.2 Windows 安装向导要点

下载最新安装包后，双击启动安装向导。整个安装过程非常简单，只需留意以下几个界面即可：

GNU 许可协议：安装向导会展示 GNU General Public License（GPL）。记住 Git 是免费的开源软件，阅读后继续即可（见 Day36_Git3.png）。
选择附加组件（Select Components）：这里可以勾选希望随 Git 一起安装并关联的组件。在 Windows 上，通常建议安装Git Bash，它允许你在 Windows 上直接运行 bash 脚本，是与仓库内 2022/Days/Linux 章节中 bash 实践衔接的桥梁。
选择 SSH Executable：选择要使用的 SSH 可执行文件。保持默认的随 Git 捆绑的 OpenSSH即可——这部分内容在 90DaysOfDevOps 的 Linux 章节中有过介绍（OpenSSH 相关知识见 2022/Days/Linux 目录）。
实验性功能（Experimental Features）：按需勾选。作者本人不需要这些实验性选项，因此不勾选；如果日后需要，也可以重新进入安装流程随时添加。
安装完成：向导完成后，可以勾选"打开 Git Bash"和"查看发布说明（Release Notes）"。

需要特别说明的一点：Git 的安装向导在安装最新版之前，会先卸载旧版本。这意味着上述流程对"从零安装 Git"的情形同样适用，不必担心需要手动清理旧版本。

安装完成后，回到 PowerShell 再次运行git --version，确认已经升级到最新版本。

2.3 Linux / Ubuntu 更新 Git

在 Linux 机器上，如果检查发现版本落后，最简单的更新方式是：

sudo apt-get install git

如果希望始终获取 Git 官方 PPA 提供的最新版本（而不是发行版仓库中固定的较旧版本），可以使用下面这组命令，它会先把 Git 的官方软件源（PPA）添加到 apt 源中，再执行更新与安装，最后校验版本：

sudo add-apt-repository ppa:git-core/ppa -y sudo apt-get update sudo apt-get install git -y git --version

提示：add-apt-repository仅在 Ubuntu 及其衍生发行版（如 Debian 系带该工具的环境）中可用；在无此工具的发行版上请改用官方源码编译或其他包管理器方案。

2.4 安装完成后的验证清单

无论使用哪个平台，安装完成后都建议确认：

git --version能正确输出版本号；
git bash（Windows）或终端（Linux）可以正常启动；
下一步的git config配置可正常执行（见下一节）。

三、首次使用的全局配置：三个层级与关键配置项

当我们第一次使用 Git 时，需要预先定义一些设置，它们会在每次提交时被写入提交记录：

Name（姓名）
Email（邮箱）
Default Editor（默认编辑器）
Line Ending（换行符）

这些配置可以在三个不同的层级（level）上完成：

配置层级	作用范围	命令示例
`system`	全部用户（系统级）	`git config --system ...`
`global`	当前用户的全部仓库	`git config --global ...`
`local`	当前仓库	`git config --local ...`（不指定层级时默认为 local）

3.1 设置用户名与邮箱

最基础的两条全局配置是作者姓名和邮箱，它们会出现在每一次提交的历史记录中：

git config --global user.name "Michael Cade" git config --global user.email "Michael.Cade@90DaysOfDevOps.com"

请替换为与你自己的代码托管账号（如 GitHub/GitLab）一致的信息，这样提交记录才能正确归属到你名下。邮箱既可以使用真实邮箱，也可以使用各平台提供的隐私保护邮箱。

3.2 设置默认编辑器

默认的文本编辑器由操作系统决定。在作者的 Ubuntu 机器上，如果不进行任何设置，Git 默认使用nano（例如打开提交信息编辑、合并冲突编辑时）。下面的命令将默认编辑器更改为 Visual Studio Code：

git config --global core.editor "code --wait"

--wait参数表示 Git 会等待 VS Code 关闭该文件后才继续执行后续操作，这是 Git 与编辑器协作时的关键约定。除了 VS Code，也可以设置为vim、nano等任意编辑器命令。

3.3 查看与直接编辑全部配置

如果想查看所有 Git 配置，可以使用：

git config --global -e

这条命令会用前面设置的默认编辑器直接打开配置文件。实际上，在任何机器上，这个文件都命名为.gitconfig；在 Windows 上，它位于你的用户账户目录（如C:\Users\micha\.gitconfig，见 Day36_Git11.png），在 Linux 上则位于家目录（如/home/michael/.gitconfig，见 Day36_Git10.png）。

从文档中展示的真实.gitconfig示例（Day36_Git10.png）可以看到，一个典型的配置文件通常包含以下区块：

[user] name = michaelcade email = michael.cade@outlook.com [credential] credentialStore = cache helper = /usr/bin/git-credential-manager-core helper = /mnt/c/Program Files/Git/mingw64/libexec/git-core/git-credential-wincred.exe helper = store [credential "https://dev.azure.com"] useHttpPath = true [commit] gpgsign = false [gpg] program = gpg2

这些配置展示了几个常见实践：通过[user]区块固定作者身份；通过[credential]区块配置凭证存储与辅助工具（Git Credential Manager Core、Windows 的 wincred 助手、store明文存储等），便于在 HTTPS 推送时免重复输入账号密码；[credential "https://dev.azure.com"]针对特定远程地址启用useHttpPath；[commit]区块的gpgsign = false与[gpg]区块则涉及提交签名（GPG）的相关设置。你可以直接在编辑器中增删这些区块，保存后即生效。

要查看当前生效的全部配置值，也可以使用不带-e的读取命令：

git config --list

四、Git 理论：客户端-服务器与分布式版本控制的对比

在 Day 35 的概述（第三十五天）中已经提到，版本控制有多种类型，可以划分为两大类：客户端-服务器（Client-Server）与分布式（Distributed）。

4.1 客户端-服务器版本控制模型

在 Git 出现之前，客户端-服务器是版本控制的事实标准，典型代表是 Apache Subversion (SVN)，一个 2000 年建立的开源版本控制系统。

该模型的核心流程如下：

第一步：从服务器下载代码。开发者从中心服务器下载源代码和实际文件到本地进行工作（见 Day36_Git12.png）。
第二步：提交与冲突。当两个开发者修改同一个文件时，先完成修改并提交（上传）到服务器的人"赢得比赛"；当第二位开发者想要提交自己的修改时，就会遇到冲突（conflict）（见 Day36_Git13.png）。
第三步：解决冲突后提交。此时开发者需要先把第一位开发者的代码变更拉取下来，与自己的修改对照，在冲突全部解决之后，才能再次提交（见 Day36_Git15.png）。

需要强调的是：这种模型不会消除冲突，但它降低了冲突的复杂度，让开发者有清晰的处理路径可循。客户端-服务器模型下，开发者之间不能直接交换代码，所有变更都必须经过中心服务器中转。

4.2 分布式版本控制模型（Git 所属）

Git 并不是唯一的分布式版本控制系统，但它如今已是事实标准。Git 的主要优势可以概括为：

快速（Fast）
智能（Smart）
灵活（Flexible）
安全（Safe & Secure）

与客户端-服务器模型截然不同的是：在分布式模型中，每个开发者都会下载源仓库的全部内容——包括完整的提交历史、全部分支、全部标签等，每个人的本地克隆都是一个完整仓库（见 Day36_Git16.png）。正如图中说明所强调的：可能有一个主来源（main source），但这是一个对等（peer-to-peer）的网络，所有开发者都持有全部数据。

分布式模型带来的直接好处：

本地提交与历史查询完全离线可用（git log、git diff等操作不需要联网）；
任何一台机器上的完整克隆都可以作为备份与恢复源；
协作时通过clone、push、pull、merge完成对等同步，不依赖单点服务器；
每个克隆都携带完整历史，天然具备安全性与容灾能力。

4.3 两种模型对比小结

维度	客户端-服务器（如 SVN）	分布式（如 Git）
中心服务器	必需，所有提交必须经过服务器	可以有主来源，但不是必需
开发者本地数据	仅文件副本	完整仓库（全部历史与分支）
冲突处理	存在，提交前必须拉取并解决	存在，通过本地合并工具处理
离线工作	受限	完整支持
典型代表	Apache Subversion (2000)	Git

五、在 90DaysOfDevOps 仓库中的实际应用与延伸

本文所讲的安装与配置流程，在 90DaysOfDevOps 项目中有着非常实际的应用场景：该仓库本身就是一个使用 Git 进行版本控制的"学习公开"项目，整个 2022 系列（2022/zh_cn/Days）每天一篇 Markdown 笔记，配合图片（2022/Days/Images）持续演进。当你 fork 并克隆这个仓库时，git clone会把你本地的克隆变成一份包含完整提交历史的分布式仓库——这正是第 4.2 节所述"每个开发者都持有完整仓库"的直观体验。

如果你想以贡献者身份参与此类项目，仓库的 CONTRIBUTING.md 给出了基于 Git 的标准协作流程，其中与本文知识点直接相关的命令包括：

# 关联上游仓库 git remote add upstream https://github.com/MichaelCade/90DaysOfDevOps.git # 基于 main 创建功能分支 git checkout -b my-new-feature main # 保持与上游同步（fetch + rebase） git fetch -a git pull --rebase upstream main # 修正最后一次提交信息后强制推送 git add . git commit --amend git push --force-with-lease origin my-new-feature

这些命令覆盖了git config（作者信息）、git clone/git remote（远程仓库）、git checkout -b（分支）、git pull --rebase（同步）、git commit --amend（改写历史）与git push --force-with-lease（安全推送）等知识点，可以作为学完安装配置后的第一个实战练习。其中--force-with-lease相比--force更安全，它会在远程有他人新提交时拒绝覆盖——这一点在 Day 37 的 Push 命令表中也强调过"不要轻易使用--force"。

六、常见问题与下一步

Q：系统提示 git 命令不存在？A：说明尚未安装或未加入 PATH。Windows 下重新运行安装包并确保勾选"Add to PATH"；Linux 下执行sudo apt-get install git -y。

Q：提交时提示需要设置 user.name / user.email？A：按第 3.1 节执行两条git config --global命令即可。

Q：Windows 与 WSL 里同时使用 Git，配置是否冲突？A：两者使用各自的.gitconfig（Windows 在用户目录、WSL 在家目录），可分别配置；也可以通过git config --global includeIf按路径条件引入统一配置。

Q：如何知道某个配置项当前生效的值？A：git config --global --list查看全局配置；git config --list --show-origin可以同时显示每个配置项来自哪个文件。

下一步建议直接进入了解 Git 常用命令（Day 37），该篇整理了从基本操作（init/clone/add/commit/status/log/diff）、撤销更改（revert/reset/clean）、重写历史（commit --amend/rebase/reflog）、分支（branch/checkout/merge）到远程仓库（remote/fetch/pull/push）的完整命令速查表，配合本文的安装配置即可直接上手。