很多开发者第一次接触 Git都是从“装个客户端”开始的。下载一个安装包一路 Next装完打开命令行敲git --version看到版本号就觉得自己环境搭好了。等到真正克隆仓库、提交代码、推送远程的时候各种莫名其妙的问题就冒出来了——fatal: not a git repository、换行符警告、中文乱码、SSH 密钥连不上。这时候往往才意识到Git 环境搭建这件事装软件只占三分另外七分是配置和认知。这篇内容我基于自己这些年在新机器上折腾 Git 环境的经验把从安装到配置、再到日常使用的完整链路整理出来。不管你是 Windows 用户、macOS 用户还是 Linux 用户只要能按照这篇文章走一遍你的 Git 环境就能达到一个“可以放心长期使用”的状态。文章里涉及的报错排查和配置细节都是我在实际开发中踩过坑之后沉淀下来的希望能帮你省下一些不必要的时间。1. 动手安装之前先想清楚三件事Git 环境搭建之所以比普通软件安装复杂是因为它涉及的不只是“装一个软件”而是“装完软件之后让这个软件和你的操作系统、你的编辑器、你的远程仓库平台、你的团队协作习惯全部对齐”。所以在一开始我建议你先想清楚三个问题。第一个问题你日常主要在哪个平台工作Windows 和 macOS 的安装方式、配置路径、命令行工具都不一样。Windows 上有 Git Bash、PowerShell、CMD 三种终端环境它们的表现差异很大macOS 自带 Git 但不是最新版本Linux 下用包管理器安装也要区分不同发行版。这些细节决定了你后面每一步操作的方式。第二个问题你和远程仓库平台的对接方式是 HTTPS 还是 SSH很多人以为 Git 环境搭好之后克隆仓库就直接能用。其实克隆 GitHub、Gitee、GitLab 上的私有仓库都需要提前做好认证配置。HTTPS 方式每次都要输用户名密码或者配置凭据管理器SSH 方式需要生成密钥对并把公钥填到平台后台。选错了方式后面会非常痛苦。第三个问题你的 Git 版本是否足够新Git 也在持续迭代旧版本对新的认证协议支持不完善甚至会有安全问题。比如 2021 年底曝出的 CVE-2021-44228Log4j2 漏洞和 Git 本身关系不大但 Git 历史上也有过多次安全更新版本太旧会让自己暴露在已知风险中。所以安装时尽量去官网下载最新稳定版不要用系统自带的老版本。想清楚这三件事再开始动手你会发现自己比身边很多同事少踩一半的坑。1.1 Git 环境不止是“装 Git”这么简单完整定义一个“可用的 Git 环境”至少包含四个层面Git 核心程序、终端或图形界面工具、全局配置、以及与远程平台的认证通道。大多数人只完成了第一层后面三层完全停留在默认状态这就导致后续各种奇怪问题的出现。以 Windows 为例很多人装 Git 的时候选择默认选项装完之后发现 Windows 自带的 CMD 里也能敲 Git 命令了就以为大功告成。实际上Git for Windows 默认会附带安装 Git Bash这才是 Windows 下体验最接近 Linux 的终端环境。很多教程里的命令在 Git Bash 里能跑通在 PowerShell 里却可能因为转义规则不同而报错。这不是 Git 的问题是你没把“环境”这个概念理解完整。另一个很容易被忽略的是系统环境变量。装 Git 的时候如果选择了“仅从 Git Bash 使用 Git”那你的 PATH 里就不会有 Git 的路径CMD 和 PowerShell 里敲git命令就没反应。这也是“环境没有真正搭好”的典型表现。后面我会在安装环节具体讲怎么选。1.2 区分“工具使用者”和“工具维护者”Git 环境搭建这件事不同的人需要投入的精力不同。如果你是写代码的大多数情况下只需要把 Git 用熟练但如果你想搭建一套团队级别的代码托管流程或者你需要在 CI/CD 流水线里使用 Git那你就需要理解仓库初始化、分支策略、钩子脚本、凭据存储这些更深层的东西。这篇文章的核心定位是“个人开发环境搭建”所以我主要覆盖到一个开发者日常需要的全部内容。如果你是团队里的配置管理员或者 DevOps 角色文章后半部分关于远程认证、多密钥管理、环境迁移的内容也会对你有用但你可能还需要额外学习服务端 Git 仓库的部署。2. 三大平台的安装实操与选型对比Git 官方提供了 Windows、macOS、Linux 三大平台的安装包和安装方式。每个平台的细节差异不小我分开来说你可以直接跳到对应自己平台的章节。2.1 Windows别只会一路 NextWindows 下安装 Git推荐去官网下载 Git for Windows 安装包。下载的时候注意两个细节一是选择 64 位版本现在的电脑基本都是 64 位的二是认准官网域名网上有很多第三方站点挂着 Git 下载链接但捆绑了杂七杂八的东西官网下载是最安全的。安装过程中有几个选项对后续使用影响很大这里单独拎出来讲。第一个是“Select Components”界面注意把 “Git Bash Here” 和 “Git GUI Here” 勾上。这两个选项能在文件夹右键菜单里加入入口用起来非常方便。默认是勾上的但如果你之前装过其他工具改过配置建议检查一下。第二个是“Choosing the default editor used by Git”。Git 默认用 Vim 作为提交信息的编辑器很多新手在git commit的时候不小心进了 Vim不知道怎么退出只能在网上搜“如何退出 Vim”搜到的答案五花八门有人甚至直接关掉终端导致提交失败。我建议在这里直接选 Visual Studio Code或者你平时常用的编辑器比如 Notepad。这样每次需要输入提交信息的时候会打开你熟悉的编辑器体验好很多。第三个是“Adjusting the name of the initial branch in new repositories”。新版 Git 默认让你选择初始分支名是master还是main。如果你是自己用选哪个都行但现在 GitHub 上新建仓库默认分支已经改成了main为了保持一致建议选main。这个选择只在git init创建新仓库时生效对克隆已有仓库没有影响。第四个是“Adjusting your PATH environment”。这里有三个选项默认是中间那个“Git from the command line and also from 3rd-party software”意思是可以从 CMD 和 PowerShell 里使用 Git。这个比较推荐。如果你选第一个“Use Git from Git Bash only”那 CMD 和 PowerShell 里就用不了 Git 了很多开发工具比如 VS Code 的终端调用 Git 时会找不到命令非常麻烦。第五个是行尾转换的选项这个直接关系到跨平台协作我会在配置章节重点展开安装时可以先用默认的 “Checkout Windows-style, commit Unix-style line endings”。安装完成后验证方式是在任意目录打开 Git Bash运行git --version。如果能看到版本号说明安装成功且环境变量设置正确。你还可以运行which git看看 Git 执行文件的实际路径确认是从哪个目录调用的。2.2 macOS自带 Git 与 Homebrew 的选择macOS 系统自带 Git但版本通常比较旧。你可以在终端里运行git --version看看旧版本对某些新特性支持不好而且苹果自家的 Git 和官方 Git 的编译配置也有差异。所以如果你是 macOS 用户我建议用 Homebrew 重新装一个最新版。如果你还没装 Homebrew先安装 Homebrew安装过程比较长但它是一个值得一次投入的工具。装好之后运行brew install git安装完成后注意一个细节macOS 自带的 Git 在/usr/bin/gitHomebrew 装的在/opt/homebrew/bin/gitApple Silicon或/usr/local/bin/gitIntel。需要确认系统实际调用的是哪个版本运行which git如果显示的是/usr/bin/git说明还在用旧版本。这时候需要调整 PATH 的顺序让 Homebrew 的 Git 优先在~/.zshrc里加一行export PATH/opt/homebrew/bin:$PATH然后执行source ~/.zshrc再运行which git应该就能看到 Homebrew 的路径了。这一步很关键因为很多工具在安装 Git 相关插件或者执行 Git 操作时依赖的是一个可用的 Git 路径。macOS 还有一个坑是首次运行 Git 会触发系统的开发者工具安装弹窗。如果你运行git命令时系统提示安装 Command Line Tools可以直接点安装也可以先运行xcode-select --install提前装好。2.3 Linux包管理器与源码编译怎么选Linux 下安装 Git 最为方便绝大多数发行版都可以直接用包管理器安装。Debian/Ubuntu 系列sudo apt update sudo apt install gitCentOS/RHEL/Fedora 系列sudo yum install git # 或者新版 Fedora 用 sudo dnf install git装完同样用git --version验证。这里要说一个现象有些发行版自带的 Git 版本也比较旧如果你的开发场景对 Git 版本有要求比如需要用到git switch、git restore这类新命令或者需要支持新的 SSH 签名建议添加 Git 官方提供的源。以 Ubuntu 为例可以使用 Git 官方维护的 PPAsudo add-apt-repository ppa:git-core/ppa sudo apt update sudo apt install git对于追求最新版本、或者想定制编译参数的场景可以源码编译安装。Git 的依赖不算复杂基本只需要make、gcc、libcurl和zlib这些基础组件。官方文档对编译安装有专门说明大致流程是下载源码包、解压、运行make configure ./configure --prefix/usr/local make sudo make install。但坦率地讲对绝大多数开发者来说用包管理器安装完全够用源码编译只在特殊环境下才需要不必为“显得专业”而在这上面花时间。Linux 用户还有一个额外的注意事项如果遇到权限问题可能是当前用户不在git命令的执行路径上。通常 Git 会安装在/usr/bin/gitPATH 里默认就有不需要额外设置。但如果你自己指定了安装路径记得把路径加到~/.bashrc或~/.zshrc里。3. 安装完成后必须做的几件配置Git 装好只是开始。如果不去设置全局配置你的 Git 环境仍然处于“半残疾”状态。下面这几项配置是无论你用什么平台、什么工作场景都必须要做的。3.1 全局身份设定提交记录里的“名片”Git 的每次提交都会记录作者信息这个信息来自user.name和user.email配置。如果没有设置Git 会尝试从系统用户名和主机名推断结果就是提交记录里出现一堆乱七八糟的名字在代码评审和版本回溯的时候非常难定位问题。设置命令很简单git config --global user.name 你的名字 git config --global user.email 你的邮箱这里的邮箱建议填写你在 GitHub/Gitee 等平台绑定过的邮箱这样提交记录才能和你的平台账号关联上你的提交会正确显示在你的贡献日历里。如果你出于隐私考虑不想暴露真实邮箱GitHub 支持使用类似usernameusers.noreply.github.com的隐私邮箱你可以在 GitHub 后台的 Email 设置里找到这个地址填到 Git 配置里。配置完了可以验证git config --global --list这个命令会列出所有全局配置项看到user.name和user.email输出正确就说明配置生效了。如果你在不同项目里需要不同的身份信息比如一个用于公司项目、一个用于个人项目可以在项目目录下用不加--global的git config user.name/email单独设置项目级配置会覆盖全局配置。3.2 行尾与编码问题跨平台协作的第一场灾难这是 Windows 用户最常遇到的坑。Windows 的文本文件用回车加换行CRLF作为行尾而 Linux/macOS 用换行LF。如果不做任何配置同一份文件在 Windows 和 Linux 之间来回切换时Git 会认为整个文件的每一行都变了产生大量无意义的 diff代码评审的人看到几百行全是波浪线心态直接崩掉。解决方法是配置 Git 的core.autocrlf参数。推荐配置是 Windows 上设置为truegit config --global core.autocrlf true效果是检出代码时把 LF 转换成 CRLF提交时把 CRLF 转换回 LF。这样在 Windows 本地编辑没问题提交到仓库里的始终是 LF和 Linux 协作时不会因为行尾产生冲突。macOS 和 Linux 用户推荐设置git config --global core.autocrlf input意思是提交时把 CRLF 转成 LF但检出时不转换。这样能确保仓库里统一是 LF但不会在本地生成额外的 CRLF。如果你的团队里既有 Windows 又有 Mac/Linux更推荐的方式是在仓库根目录放一个.gitattributes文件对不同文件类型强制指定行尾规则。比如* textauto *.sh text eollf *.bat text eolcrlf* textauto表示让 Git 自动判断文本文件并统一处理行尾针对脚本文件再指定具体的行尾规则比如.sh脚本在 Windows 上也应该以 LF 保存否则运行时会报错Windows 下写 bash 脚本默认保存成 CRLF 会导致脚本无法执行。.gitattributes文件提交到仓库后团队所有人都会自动遵循同一个规则。3.3 常用别名与默认行为设置Git 命令有不少是组合参数每次敲完整命令很累人。配置别名可以大幅提升效率。我自己的通常配置git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.lg log --oneline --decorate --graph --all配置完成后git st就等于git statusgit lg可以以一图流形式查看所有分支的提交历史。别名的好处不仅是少敲几个字母还在于把这些高频操作固化成一个稳定模式减少输入错误。除了别名还有几个默认行为值得设置git config --global init.defaultBranch main git config --global pull.rebase false git config --global push.default simpleinit.defaultBranch main让git init创建的仓库默认分支叫main而不是masterpull.rebase false表示git pull默认使用 merge 方式而不是 rebase 方式这对习惯传统 Git 工作流的人来说更直观push.default simple是推送到上游分支的安全默认值在 Git 2.0 之后已经是默认了显式设一遍更明确。3.4 SSH 密钥生成与本地配置和远程仓库打交道认证是绕不开的一环。SSH 方式认证核心是密钥对本地生成一个私钥和一个公钥私钥留在本地公钥填到 GitHub/Gitee 后台。之后本地和远程之间的通信就通过密钥自动完成认证不需要每次输密码。生成密钥的命令是ssh-keygen -t ed25519 -C 你的邮箱这里推荐用ed25519算法而不是传统的 RSA。ed25519 密钥更短、生成更快、安全性也足够GitHub 和 Gitee 都已经支持。命令会让你选择保存路径默认在~/.ssh/id_ed25519直接回车用默认即可。还要设置一个 passphrase口令这是用来保护私钥的密码建议设置一个不容易忘记的。如果设置了 passphrase每次使用私钥时需要输入一次可以通过ssh-agent记住省去反复输入的麻烦。生成完成之后在~/.ssh目录下会有两个文件id_ed25519私钥和id_ed25519.pub公钥。公钥的内容可以查看并复制cat ~/.ssh/id_ed25519.pub复制输出的一整行内容到 GitHub 的 Settings - SSH and GPG keys - New SSH key 里粘贴标题随意用于区分不同电脑即可。Gitee 类似在设置里的 SSH 公钥页面粘贴保存。配置完成后测试一下连通性ssh -T gitgithub.com看到类似 “Hi username! Youve successfully authenticated, but GitHub does not provide shell access.” 的输出就说明认证已经通了。Gitee 则是ssh -T gitgitee.com输出 “Hi 用户名! Youve successfully authenticated, but Gitee does not provide shell access.” 表示成功。3.5 检查环境是否就绪的完整清单配置做完之后建议在本地建立一个测试仓库把整个流程走一遍确保一切正常。这样比直接在真实项目里摸索要安全得多。mkdir ~/git-test cd ~/git-test git init echo # Test README.md git add README.md git commit -m first commit git log --oneline如果git commit能顺利执行git log能看到一条提交记录说明本地仓库工作正常。接着可以测试远程仓库的连通性用前面配置好的 SSH试着在 GitHub 上建一个空仓库然后在本地执行git remote add origin gitgithub.com:你的用户名/仓库名.git git push -u origin main推送成功后再加一个文件提交推送一次确认推拉都通畅。这套流程走下来你的环境就可以正式投入使用了。4. 与远程仓库对接Gitee 与 GitHub 的配置细节本地 Git 环境搭好之后真正的工作流是和远程仓库协同。这一节专门讲远程对接中那些容易出问题的细节。4.1 SSH 公钥配置从生成到验证的全流程如果你在 3.4 节已经按流程生成了密钥并配置了公钥那这一节你可以直接跳到 4.2 去了解 HTTPS 与 SSH 的差异。但如果你想把多台电脑都接入同一个账号或者你需要在同一台电脑上同时使用多个代码托管平台的账号就需要对 SSH 的配置文件有更深的理解。SSH 客户端的配置文件在~/.ssh/config可以针对不同主机配置不同的密钥。比如你想让 GitHub 用默认的id_ed25519让 Gitee 用另一把密钥可以在配置里写Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519 Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/gitee_ed25519这样在克隆和推送时SSH 会根据连接的域名自动选择对应的密钥文件。生成多把密钥的流程和单把一样只是在ssh-keygen时指定不同的文件名即可ssh-keygen -t ed25519 -C githubexample.com -f ~/.ssh/id_ed25519 ssh-keygen -t ed25519 -C giteeexample.com -f ~/.ssh/gitee_ed25519把各自的公钥分别填到对应平台密钥就不会串了。4.2 HTTPS 与 SSH 两种远程方式的取舍克隆远程仓库的时候你可以选择 HTTPS 地址或者 SSH 地址。两者的区别主要体现在认证方式上。HTTPS 方式在克隆时不需要预先配置密钥直接输入平台用户名和密码或者访问令牌就能克隆。但每次推送都需要输入凭据虽然可以配置 Git 凭据管理器来记住但凭据存储本身又是一个安全风险点。而且有些平台已经不再接受密码方式只允许使用个人访问令牌这对小白来说又多了一层理解成本。SSH 方式前期需要生成并配置密钥但配好之后后续完全免密操作体验顺畅很多。对开发环境来说我基本上无脑推荐 SSH。尤其是你在服务器上部署项目时用 SSH 方式拉取代码配合服务器的部署密钥不需要在服务器上保存账号密码安全性更好。如果你已经在用 HTTPS 方式并且不想切换可以考虑配置凭据管理器。Windows 上安装 Git 时默认会带 Git Credential ManagermacOS 上也可以配置 osxkeychain。这些工具会安全地把凭据保存在系统的凭据存储区后续不需要重复输入。4.3 多个平台多个密钥的管理办法很多开发者除了 GitHub、Gitee还会用到公司内部的 GitLab以及可能自己搭建的 Gitea 服务。多平台多密钥的管理是典型的“环境搭建后期问题”处理不好容易把密钥弄混出现“推送到 GitHub 用的是 Gitee 的密钥”这种错误。管理口诀是一个平台一把密钥通过~/.ssh/config文件指定对应关系。具体方法在 4.1 已经写了这里补充两个技巧。第一个技巧是测试时用-T参数看返回信息确认用的哪把密钥。比如ssh -T gitgitlab.company.com返回信息里会显示这个连接使用的用户名可以帮助你确认密钥是否匹配。第二个技巧是不要随意修改~/.ssh目录的权限。SSH 客户端对私钥文件的权限要求很严格私钥文件不要设置为其他用户可读否则 SSH 会拒绝使用。如果你复制了~/.ssh目录到新电脑或者系统权限出现异常可以手动修正chmod 700 ~/.ssh chmod 600 ~/.ssh/id_ed25519每次换新电脑把~/.ssh目录里的密钥复制过去再按这个命令设置权限就能无缝恢复 SSH 登录。5. 环境搭好后最常踩的一线错误及排查链路环境搭好之后你以为就完事了吗实际上后续开发过程中还会有一堆问题冒出来。这里我挑三个最典型的错误把完整的排查链路拆给你看下次遇到问题能自己定位不用满网找答案。5.1 fatal: not a git repository 的完整排查链路这个报错几乎是 Git 初学者遇到最多的错误完整信息是fatal: not a git repository (or any of the parent directories): .git。出现这个错误第一反应应该是你当前所在的目录不是 Git 仓库或者你不在仓库的任何一个子目录里。比如你在~目录下直接敲git status如果没有在这个目录初始化过仓库就会报这个错。排查链路分三步走。第一步确认自己当前在哪个目录用pwd查看。第二步确认这个目录或者它的父目录里有没有.git目录用ls -a查看。如果确实没有说明你需要用git init初始化仓库或者cd到已经 clone 下来的仓库目录里。第三步如果你确信自己在仓库目录里但仍然报错可能需要检查环境变量GIT_DIR是否被设置成了不存在的路径。运行env | grep GIT查看如果有输出说明某个工具帮你设置了仓库路径但路径不对。一个常见的变体是你把 Git 仓库目录放到了云盘同步目录里比如 OneDrive、坚果云云盘在同步过程中把.git目录搞坏了。这种问题定位周期很长建议 Git 仓库目录不要放在云盘同步路径下。5.2 LF 与 CRLF 警告到底要不要管新手在 Windows 上拉取项目代码时经常会看到类似这样的警告warning: LF will be replaced by CRLF in package.json. The file will have its original line endings in your working directory.很多人的第一反应是“是不是文件有问题了”其实不是。这个警告是在提醒你Git 根据你的core.autocrlf配置会在提交时把工作区里的文件行尾做一次转换。如果你已经按前面说的设置了core.autocrlf true这个警告只是提示行为不是错误可以忽略。但如果一个项目里出现了大量这种警告而且你并不是有意改变文件内容可能说明项目的.gitattributes配置缺失或者仓库里的文件本身混用了多种行尾。最稳妥的处理方式是在项目根目录添加.gitattributes并强制刷新行尾git add .gitattributes git add --renormalize . git commit -m Normalize line endings--renormalize会按照.gitattributes规则重新标准化所有文件的行尾一次解决历史遗留的混用问题。5.3 中文乱码与提交信息乱码的修复Git 在 Windows 下显示中文文件名或者中文提交信息时经常会出现乱码。这个问题的根源通常是字符编码不一致。Windows 终端默认使用 GBK 编码而 Git 内部使用 UTF-8两者不一致就会显示乱码。修复方法有两层。第一层是修改 Git 的显示配置让 Git 输出 UTF-8 时终端能正确解码。在 Git Bash 里执行git config --global core.quotepath false git config --global gui.encoding utf-8 git config --global i18n.commit.encoding utf-8 git config --global i18n.logoutputencoding utf-8core.quotepath false尤其重要它让 Git 显示中文文件名时不再转义成八进制编码。如果你仍然乱码第二层是修改终端的编码设置。在 Git Bash 窗口上右键打开选项在 Text 设置里把编码从 GBK 改成 UTF-8。大多数情况下这两层组合就能解决乱码问题。另外还要注意有些人的乱码是编辑器保存文件时使用了错误编码比如 VS Code 或者 Notepad 默认用 GBK 保存源文件。这种问题属于编辑器配置层面建议把编辑器的默认文件编码统一设置为 UTF-8新文件默认就是 UTF-8避免后续提交内容出现编码混杂。6. 让环境更好用的进阶配置与日常操作姿势基础的安装和配置完成之后Git 环境已经可以支撑日常开发了。但如果你想把环境调校到“顺手”的程度还有一些进阶配置和操作习惯值得养成。6.1 git commit --amend 的正确使用时机git commit --amend是很多初学者会好奇的命令它的作用是把暂存区的内容追加到上一次提交。具体使用场景有两个一是上一次提交忘掉了一个文件或者提交了之后发现一个低级错误想在不增加额外提交记录的情况下修正二是修改上一次提交的提交信息比如信息写得不清楚、有错别字。基本用法是git add 遗漏的文件 git commit --amend执行后编辑器会打开让你修改提交信息也可以直接用git commit --amend -m 新的提交信息这里必须提醒一个关键禁忌--amend会改变提交的 hash 值。如果这次提交已经推送到了远程仓库并且你的队友已经基于这个提交做了其他操作那你修改之后再强制推送会导致队友的本地历史和你对不上造成不必要的麻烦。所以--amend只适用于“提交之后发现遗漏但要还没推送”的场景。如果已经推送了就老老实实再发一个新提交不要动已经公开的历史。6.2 .gitignore环境搭建里最容易漏掉的环节项目仓库里哪些文件不该提交是环境搭建阶段就该想清楚的问题。很多人是等到把 IDE 配置文件、编译产物、本地环境配置一股脑提交到仓库之后才追悔莫及。.gitignore文件的作用就是告诉 Git 哪些文件忽略掉不纳入版本管理。一个典型的.gitignore会根据项目语言和工具链选择对应的忽略规则。比如 Python 项目要忽略__pycache__/、*.pyc、.venv/Node.js 项目要忽略node_modules/Java 项目要忽略target/。我见过很多团队把.gitignore当成事后诸葛亮项目已经建立了很久才想起来加结果就是历史提交记录里已经混入了大量没有必要的文件即使后来加了.gitignore已经追踪的文件在下次修改时依然会被提交。一个技巧是如果文件已经被 Git 追踪你需要先把它们从索引中移除再让.gitignore生效git rm -r --cached . git add . git commit -m Apply gitignore rules--cached参数的意思是只从 Git 索引中删除并不会删除你磁盘上的文件。执行之后重新提交Git 不会继续追踪这些文件。全局的.gitignore配置也有必要设置比如可以创建一个~/.gitignore_global文件写入一些常见的系统级杂项文件.DS_Store、Thumbs.db等并通过git config --global core.excludesfile ~/.gitignore_global全局引用。这样你在任何仓库里都不会误提交这些系统垃圾文件。6.3 环境体检、备份与迁移环境搭建好之后我建议你花十分钟做一次“环境体检”同时把配置备份下来。Git 的全部核心配置都在三个层级的文件里系统级/etc/gitconfig、全局级~/.gitconfig、项目级.git/config。日常开发中你自己修改的主要是全局级配置文件。备份全局配置最直接的方式是git config --global --list把输出结果记录下来或者直接用cp ~/.gitconfig ~/.gitconfig.bak更好的方式是把这份配置文件存到一个代码仓库里管理起来配合一份简单的安装脚本以后换电脑或者在服务器上部署环境直接拉取配置就能快速恢复。我自己在换新电脑或者给服务器初始化环境的时候从来不会从头敲一遍配置命令而是把之前备份的gitconfig、.gitignore_global、~/.ssh/config复制过去再重新生成密钥、填写公钥整个过程五分钟左右。还要提醒一个细节如果配置里使用了绝对路径比如某些自定义的core.editor路径、filter钩子脚本路径换电脑之后要检查这些路径是否还存在。举个例子你在 Windows 上配置了 VS Code 编辑器路径复制配置到 Linux 上时路径很可能就失效了。所以环境迁移之后建议先跑一遍git status和git config --global --list确认没有异常。最后再分享一个我个人的小习惯每次安装完 Git 环境我都会在终端里敲一遍这几条命令作为“环境是否就绪”的固定验收。git --version git config --global --list ssh -T gitgithub.com三条命令分别验证程序安装、配置完整性、远程认证通道全部通过这份环境才算真正达到可以放心使用的状态。后续如果哪一天莫名其妙出现奇怪问题优先从这三项里排查大多数情况都能快速定位。