文档/教程【免费下载链接】90DaysOfDevOpsThis 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 打下基础。一、为什么需要安装与配置 GitGit 是开源、跨平台的版本控制工具。如果你使用 Ubuntu 或其他 Linux 发行版系统可能已经预装了 Git——正如本仓库的文档环境那样。但无论是否已经安装都建议先确认版本并尽量保持为最新版本较新版本通常会带来更快的性能、更完善的安全修复包括针对恶意仓库的防护补丁以及更好的协议支持。所以本节的目标很简单检查当前系统已安装的 Git 版本如果版本过旧或尚未安装通过官方渠道安装最新版完成身份与编辑器的首次配置保证后续每次提交commit都能记录正确的作者信息。二、安装 GitWindows 与 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 LicenseGPL。记住 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 bashWindows或终端Linux可以正常启动下一步的git config配置可正常执行见下一节。三、首次使用的全局配置三个层级与关键配置项当我们第一次使用 Git 时需要预先定义一些设置它们会在每次提交时被写入提交记录Name姓名Email邮箱Default Editor默认编辑器Line Ending换行符这些配置可以在三个不同的层级level上完成配置层级作用范围命令示例system全部用户系统级git config --system ...global当前用户的全部仓库git config --global ...local当前仓库git config --local ...不指定层级时默认为 local3.1 设置用户名与邮箱最基础的两条全局配置是作者姓名和邮箱它们会出现在每一次提交的历史记录中git config --global user.name Michael Cade git config --global user.email Michael.Cade90DaysOfDevOps.com请替换为与你自己的代码托管账号如 GitHub/GitLab一致的信息这样提交记录才能正确归属到你名下。邮箱既可以使用真实邮箱也可以使用各平台提供的隐私保护邮箱。3.2 设置默认编辑器默认的文本编辑器由操作系统决定。在作者的 Ubuntu 机器上如果不进行任何设置Git 默认使用nano例如打开提交信息编辑、合并冲突编辑时。下面的命令将默认编辑器更改为 Visual Studio Codegit 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.cadeoutlook.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 PATHLinux 下执行sudo apt-get install git -y。Q提交时提示需要设置 user.name / user.emailA按第 3.1 节执行两条git config --global命令即可。QWindows 与 WSL 里同时使用 Git配置是否冲突A两者使用各自的.gitconfigWindows 在用户目录、WSL 在家目录可分别配置也可以通过git config --global includeIf按路径条件引入统一配置。Q如何知道某个配置项当前生效的值Agit 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的完整命令速查表配合本文的安装配置即可直接上手。相关资料What is Version Control?Types of Version Control SystemGit Tutorial for BeginnersGit for Professionals TutorialGit and GitHub for Beginners - Crash CourseComplete Git and GitHub Tutorial次日篇目第三十七天 - 了解 Git赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis 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点击查看免费下载相关推荐90DaysOfDevOps 之 Git 安装与配置实战从 Windows/Linux 环境搭建到分布式版本控制原理90DaysOfDevOps 之 Git 安装与配置实战从 Windows/Linux 环境搭建到分布式版本控制原理 本篇是 90DaysOfDevOps 挑文档/教程90DaysOfDevOps 之 Day 36Git 的安装与配置——跨平台安装、三级配置与版本控制模型精讲90DaysOfDevOps 之 Day 36Git 的安装与配置——跨平台安装、三级配置与版本控制模型精讲 本文是 90DaysOfDevOps 学习地图第文档/教程90DaysOfDevOps Day 36 实战Git 跨平台安装、配置与版本控制模型深度解析90DaysOfDevOps Day 36 实战Git 跨平台安装、配置与版本控制模型深度解析 本指南基于 90DaysOfDevOps 项目第 36 天学习文档/教程上一篇WFD企业级可视化流程设计的革命性解决方案下一篇终极指南如何快速掌握RESTful API设计中的OpenAPI规范创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考