林杏仁1. 安装git之前，先搞清楚你装的到底是什么
很多人把"装个git"理解成"下载一个安装包双击下一步"，装完在命令行敲一句git --version能蹦出版本号，就以为大功告成。实际用上两天，各种莫名其妙的问题就全来了：提交上去的代码换行符乱掉、git pull要反复输密码、不同仓库的身份搞混、中文文件名显示成一串数字……这时候回头排查，根子全都在安装配置那一步埋下了。
所以这篇文章我不想只写"下载、点下一步、完成"，而是把git安装和配置这一整套东西拆开讲清楚。你会明白每个配置项到底是干嘛的、为什么这么设、哪些坑是我实际踩过之后才长记性的。内容同时覆盖Windows、macOS和Linux三种环境，无论你是刚接触版本控制的新手，还是换新电脑需要重新配环境的老手，照着做基本都能一次跑通。
先说一个基础认知。git本身是一个命令行工具，它跟GitHub、GitLab、Gitee这些平台是两码事。git是跑在你本地的一个版本管理程序，那些平台只是帮你托管远程仓库的服务商。这个关系理不清，后面配置的时候特别容易犯迷糊——很多人以为装了git就等于注册了GitHub账号，其实完全不是一回事。
另外还需要理解一个概念：git安装完之后，它本身几乎是"不可用"的。你没看错，刚装完的git连git commit都执行不了，因为git不知道你是谁。版本管理最核心的一件事，就是记录"谁在什么时间改了什么"，所以身份信息是git的硬性要求，不是可选项。这就是为什么很多教程会反反复复强调配置user.name和user.email。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 各平台的安装过程与最容易出错的细节
2.1 Windows：别默认下一步，这两个勾选项影响很大
Windows下安装git，绝大多数人用的是官方出的Git for Windows，下载地址是git-scm.com，进去之后点Downloads会自动识别系统版本。安装向导一路点Next确实能装完，但有几个界面我建议你停一下，把选项改掉再继续。
第一个是"Select Components"这个页面，里面有个Git Bash Here和Git GUI Here的右键菜单选项，默认是勾上的。建议保留，后面用起来非常方便。真正需要动的是"Default editor"这个选择——默认是Vim。如果你不熟悉Vim的操作方式（进入编辑模式要按i，退出保存要按Esc然后输:wq），建议直接选成Notepad++或者VS Code，否则以后每次git commit打开编辑器，你都会卡在"怎么保存退出"这一步。
第二个关键的页面叫"Adjusting your PATH environment"，里面有三个单选选项。一定要选中间那个**"Git from the command line and also from 3rd-party software"**，这样git命令才能在任何终端窗口里直接用。如果你选了默认的"Use Git Bash only"，打开Windows自带的CMD或者PowerShell敲git会提示找不到命令。第三个选项"Use Git and optional Unix tools from the Command Prompt"不建议选，它会把一堆Unix工具混进Windows的环境变量里，容易跟系统自带的命令产生冲突。
安装包默认装到C:\Program Files\Git，这个路径保持默认就行，不用改。装完之后打开任意终端，敲git --version，如果能看到版本号，说明安装成功。
2.2 macOS：先搞清楚你用的是Apple Silicon还是Intel芯片
macOS装git有个特殊情况：系统里可能已经预装了一个版本。苹果的Xcode Command Line Tools会自带一个git，但那个版本通常比较旧，而且某些功能被裁剪过。所以正规做法是自己装一个干净版本。
ARM芯片（M1/M2/M3系列）的Mac，建议优先用Homebrew安装，命令是brew install git。Intel芯片的Mac也可以用这个方式。装之前先确认Homebrew本身是好的，brew --version能输出版本号再继续。
还有一种方式是用官方安装包，从git-scm.com下载macOS版本的dmg文件直接安装。这种方式的好处是跟系统环境隔离得比较干净，装完在/usr/local/git/bin或者/opt/homebrew/bin下面能找到可执行文件。需要注意一个细节：macOS的SIP（System Integrity Protection）机制可能会拦截未签名的二进制文件，如果你下载的安装包提示"无法打开，因为无法验证开发者"，需要去系统设置里的"隐私与安全性"手动允许。官网的安装包是签了名的，一般不会触发这个提示，但你从网上随便下载的第三方构建版本就不好说了。
装完验证一下当前用的是哪个git：which git。如果你发现指向的是/usr/bin/git而不是Homebrew的路径，说明PATH环境变量里系统目录排在了前面。这时候要么改PATH顺序，要么干脆接受系统版本——但我建议还是改成自己装的版本，后面配置一些扩展工具时会省心很多。
2.3 Linux：包管理器安装最省事，但版本可能偏旧
Debian/Ubuntu系用sudo apt install git，CentOS/RHEL系用sudo yum install git或者sudo dnf install git，Arch系用sudo pacman -S git。这是最简单的安装方式，但有个隐患：很多发行版的软件源里git版本比较旧，默认分支名还是master而不是main，某些新特性也用不了。
要装新版本，可以用官方维护的源码编译，或者添加额外的软件源。源码编译比较麻烦，依赖多、耗时长，除非你对版本有硬性要求，否则不太推荐。日常开发用系统源里的git基本够用，版本旧一点不影响核心功能。
Linux下还有一个容易被忽略的点：如果你用apt装的git，补全脚本和文档会放在/usr/share/doc/git下面，而用源码编译的git这些文件在/usr/share/git-core下面。以后配zsh的git补全插件时，路径填错了会导致补全功能失效。
3. 安装之后立即可做的三项基础配置
3.1 身份信息：为什么必须全局配置user.name和user.email
git刚装完，第一次git commit大概率会被拒，提示"Please tell me who you are"。这就是我开头说的身份信息问题。需要配置两个值：
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
--global的意思是这台机器上所有仓库默认都用这个身份。如果你在公司的机器上，建议确认一下公司的git服务是不是要求用企业邮箱，别把个人邮箱填进去，否则提交记录里的作者信息跟公司账号对不上，代码审查系统可能无法正确识别你的身份。
这里有个细节很多人不知道：user.email并不需要是真实存在的邮箱，也不需要跟GitHub注册邮箱一致。git只是用它来做字符串匹配，把提交记录关联到某个账号上。GitHub有个功能叫"noreply邮箱"，就是在你不想暴露真实邮箱时用来提交身份的。但如果你想让提交记录正确关联到自己的GitHub头像，邮箱必须跟GitHub账号里设置的其中一个邮箱完全一致。
查看当前配置用git config --list，会输出当前仓库和全局的所有配置项。查看单项用git config user.name这种形式。
3.2 默认分支名：master和main到底怎么选
很长一段时间里，git新建仓库的默认分支名是master。近几年因为一些历史原因，越来越多的平台和社区转向用main作为默认分支名。GitHub新建仓库默认分支已经是main了，但本地git的默认值还得手动改一下才能对齐：
bash复制git config --global init.defaultBranch main
这一步不是必须的，但它能避免一个很尴尬的场景：你在本地git init初始化一个仓库，默认创建了master分支，推到GitHub上却是main分支，两边对不上，还需要手动git branch -M main重命名。提前配好就少一个麻烦。
你要是不在意分支名，用默认的master也完全没问题，这个选择纯粹是习惯问题，不涉及任何技术层面的对错。
3.3 换行符处理：Windows用户的必答题
这是git配置里最容易引发困惑的一项，没有之一。Windows系统里的文本文件默认用CRLF（回车换行）作为行尾，Linux和macOS用LF（换行）作为行尾。如果你在Windows上写代码，提交到远程仓库的文件全是CRLF，另一个同事在macOS上拉下来，git会认为每一行都变了，diff出来的结果惨不忍睹。
git有个机制叫core.autocrlf，就是处理这个问题的。Windows上建议设置：
bash复制git config --global core.autocrlf true
git config --global core.safecrlf true
core.autocrlf true的意思是：提交时自动把CRLF转成LF存进仓库，检出时再转回CRLF。这样仓库里永远存的是LF，不管你在什么系统上工作，协作时不会因为换行符产生一堆无意义的diff。
macOS和Linux用户建议设置：
bash复制git config --global core.autocrlf input
这个设置的意思是提交时把CRLF转成LF，检出时不做转换。因为macOS和Linux原生使用LF，不需要再转换回来。
core.safecrlf true的作用是当你把一个二进制文件误判成文本文件，或者某个文件里的混合换行符会引发不可逆转换时，git会直接报错而不是默默转换。这个选项可能会在个别项目上误报，但相比换行符被搞乱的代价，这个误报是完全值得的。
处理换行符还有一种更推荐的做法是在项目里放一个.gitattributes文件，明确规定哪些文件用什么换行符。它比core.autocrlf更精准，因为它是跟着项目走的，不会受个人全局配置影响。不过.gitattributes的编写涉及一些规则语法，新手先不急着搞，把core.autocrlf配好已经能解决95%的问题了。
4. 与远程仓库协作的关键配置
4.1 SSH密钥：配置一次，以后就不用反复输密码
git连接远程仓库有两种主要方式，HTTPS和SSH。HTTPS方式每次推送都需要验证用户名和密码，虽然可以借助凭证管理器记住密码，但体验还是差不少。SSH方式通过密钥对进行身份认证，配好之后推送拉取都不用输密码。
生成SSH密钥的步骤如下：
bash复制ssh-keygen -t ed25519 -C "your_email@example.com"
执行后会问你保存位置，默认是~/.ssh/id_ed25519，直接回车用默认即可。然后会让你设置一个passphrase，这是给你的私钥加的一层保护密码，可以留空也可以设一个。
生成完之后会得到两个文件：id_ed25519是私钥，绝对不能泄露；id_ed25519.pub是公钥，需要添加到远程仓库平台的后台。
把公钥内容复制到剪贴板，各平台的表现形式不太一样：
bash复制cat ~/.ssh/id_ed25519.pub
然后去GitHub的Settings -> SSH and GPG keys，或者GitLab的Preferences -> SSH Keys，或者Gitee的设置页，把公钥粘贴进去保存。
验证是否配置成功：
bash复制ssh -T git@github.com
如果是GitHub，成功会提示"Hi 用户名! You've successfully authenticated"，如果用的是GitLab或Gitee，提示内容略有不同，但大差不差。
为什么推荐用ed25519算法而不是传统的rsa？因为ed25519密钥更短、生成更快、安全性也更高。但有一个兼容性问题：如果你的公司服务器上跑的git版本比较老（比如CentOS 6/7上预装的git），可能不支持ed25519。这种情况下退回用rsa：
bash复制ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
判断当前git版本是否支持ed25519，有个笨办法：生成密钥后测试连接，如果报错说no mutual signature algorithm，就说明服务端不支持，换rsa即可。
4.2 凭证存储：解决"每次push都要输密码"的问题
如果你不想折腾SSH，坚持用HTTPS方式，那就需要配置凭证存储。Windows上git默认会弹出Git Credential Manager的窗口帮你记住密码，macOS上默认用osxkeychain，Linux上默认什么都不存、每次都让你输入。
Linux用户如果不想每次都输密码，可以用：
bash复制git config --global credential.helper cache
git config --global credential.helper "cache --timeout=3600"
这样会把密码在内存里缓存一小时，时间到了需要重新输入。想存得更久可以用store模式，但它会把密码明文存在~/.git-credentials文件里，安全性堪忧，不建议在生产环境用。
4.3 多账号场景：一台机器同时使用GitHub和公司GitLab的配置方法
很多人一台电脑上要同时使用GitHub的个人账号和公司GitLab的工作账号，这就要用到SSH config的配置了。
编辑~/.ssh/config文件（如果不存在就新建），写入类似下面的内容：
code复制Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_github
Host gitlab.company.com
HostName gitlab.company.com
User git
IdentityFile ~/.ssh/id_ed25519_work
关键点是每个Host段对应不同的域名，使用不同的私钥文件。然后在~/.ssh下生成两对密钥，分别命名为id_ed25519_github和id_ed25519_work，把对应的公钥分别添加到对应平台。
仓库克隆时用对应的域名就行，比如：
bash复制git clone git@github.com:用户名/仓库.git
git clone git@gitlab.company.com:group/project.git
git会根据ssh config自动选择合适的私钥进行认证，全程无感。
多账号还会带来一个身份混乱的问题：你在A仓库提交时，git默认还是用全局配置的user.name和user.email，这样就可能出现"公司仓库里的提交作者显示成个人邮箱"的问题。解决办法是在仓库目录下单独设置身份：
bash复制git config user.name "你的工作名"
git config user.email "你的工作邮箱"
不带--global的git config只对当前仓库生效，优先级最高。为了保险起见，建议在所有重要的仓库目录下都显式检查一下git config user.name和git config user.email，确保身份正确。
5. 提高日常使用体验的配置优化
5.1 别名：让常用命令短一半
git的命令都挺长，git checkout、git branch、git status敲起来很费手指。配置别名可以大幅提升效率：
bash复制git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm commit
git config --global alias.lg "log --oneline --graph --all --decorate"
配置完后，git st等效于git status，git co等效于git checkout，git lg能看一个带分支图和提交关系的简洁日志。
有人会问，别名的配置是不是每个仓库都要重新设一遍？加了--global就是全局的，所有仓库通用，不需要重复配置。
5.2 默认文本编码：避免中文乱码
Windows上默认的文本编码是GBK，而git默认按UTF-8处理文件内容。如果你的项目文件是GBK编码的，git diff查看改动时会显示乱码。
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-8
core.quotepath false是处理文件名乱码的关键。git默认会把非ASCII字符的文件名转义成八进制序列，显示效果就是一堆\346\265\213\350\257\225这种数字，设置成false之后就能正常显示中文文件名了。
需要说明的是，这些配置只影响git的输出和提交信息的编码处理，不改动你的文件本身。如果你的项目源文件本身就是GBK编码，那是个更大的工程问题，得从项目层面统一编码规范。
5.3 diff工具：把冲突解决变得直观
git默认的diff工具是命令行格式，遇到冲突时那场面确实让人头大。可以配置成用外部图形化工具，体验完全不同。
Windows环境配置用Beyond Compare、Meld或VS Code：
bash复制git config --global diff.tool vscode
git config --global difftool.vscode.cmd 'code --wait --diff "$LOCAL" "$REMOTE"'
git config --global merge.tool vscode
git config --global mergetool.vscode.cmd 'code --wait --merge "$REMOTE" "$LOCAL" "$BASE" "$MERGED"'
macOS上Meld用得比较多，brew install --cask meld安装后用git config --global merge.tool meld指定。
配置完后，遇到冲突场景不要直接改文件，而是运行git mergetool，会弹出图形化界面让你选择保留哪边的改动，比手动处理>>>>>>>标记直观得多。
5.4 让git自带的高亮和颜色生效
新版git默认开启了颜色显示，但有些系统上因为终端类型识别的问题会变成纯黑白输出。如果你发现git status没有任何颜色区分，执行：
bash复制git config --global color.ui true
这样git会依优先级使用颜色高亮：未跟踪文件、已修改文件、暂存区内容会以不同颜色呈现。这对快速定位工作区状态帮助很大，尤其是git status输出文件很多的时候。
6. 实测过的常见问题与排查思路
6.1 报错fatal: not a git repository
这个报错见的频率极高，原因是你在一个不是git仓库的目录下执行了git命令。解决思路很直接：确认当前目录，或者往上找有没有.git目录。git init可以把这个目录初始化为git仓库。
新手容易搞混的一点是：光有.git目录还不行，项目根目录才算仓库。你在子目录里执行git status，git会自动向上查找最近的.git目录，所以工作正常。但如果换了一台新电脑，克隆下来的项目忘记进入目录就直接敲git status，就会看到这个报错。
6.2 Windows上git bash中文显示乱码
Windows上Git Bash里中文乱码，大部分原因是终端编码跟git输出编码不对齐。在Git Bash窗口标题栏右键 -> Options -> Text -> Character set，改成UTF-8。这是Git Bash自己的设置，跟git配置无关。
改完还乱码，那就检查一下上一节说的core.quotepath和i18n相关配置。这两个层面都处理好，中文显示基本就没问题了。
6.3 修改了.gitignore但文件还是被跟踪
这是git新手最常困惑的问题之一。.gitignore只对尚未被跟踪的文件生效。如果一个文件已经被git add进暂存区或者已经提交过，那么它已经在git的跟踪列表里了，此时修改.gitignore也拦不住它。
解决办法是从git的索引里移除该文件的跟踪，但保留本地文件：
bash复制git rm --cached 文件名
--cached的含义是只从索引中删除，不删除磁盘上的文件。之后这个文件就会变成未跟踪状态，.gitignore就能正常生效了。
6.4 配置了所有东西，但git push时总提示权限问题
SSH密钥配了、身份信息也设了，结果git push还是报权限错误，这类问题的排查顺序很有讲究。
第一，确认你测试的是SSH连接还是HTTPS连接。很多人在项目里配置的remote地址是HTTPS格式的，但你生成的密钥是SSH格式的，两者根本不搭边。
查看当前项目的远程地址：
bash复制git remote -v
如果是https://github.com/...的格式，要么改用SSH地址（git remote set-url origin git@github.com:用户名/仓库.git），要么就用HTTPS加凭证管理器的方式。
第二，确认SSH密钥确实加载到了ssh-agent里：
bash复制ssh-add -l
如果显示没有身份信息，执行ssh-add ~/.ssh/id_ed25519把私钥加进去。有些发行版重启后ssh-agent不会自动加载密钥，需要写进shell的启动脚本里。
第三，检查远程仓库平台的后台，确认公钥确实添加成功，而且没添加错地方。GitHub和GitLab的公钥设置入口不是同一个位置，别把GitHub的公钥贴到GitLab上去了。
6.5 config文件直接编辑还是用命令配置
git的配置项实际上是写在三个文件里的：系统级的/etc/gitconfig、全局的~/.gitconfig、仓库级的.git/config。直接用文本编辑器改这些文件是可以的，但强烈建议还是用git config命令来改。
原因有两点：一是命令方式会自动校验配置项的合法性，你敲错了一个配置名它会立刻报错；二是命令方式层级清晰，你自己加--global就写到全局，不加就写到当前仓库，不会搞混。直接在配置文件里改的话，调久了容易忘记哪些是系统级的哪些是全局的，将来排查问题时很难理清头绪。
还有一种麻烦：配置文件里的注释和格式有讲究，手写容易出错，一个多余的空格都可能导致配置解析失败。命令方式完全不存在这个问题。
7. 一套可以直接落地的完整配置脚本
到这里，安装和配置的核心内容已经全部覆盖。下面给出一套我实测过可直接运行在全新机器上的完整配置命令，从头到尾执行下来基本就可以投入日常开发了。
Windows环境（在Git Bash里执行）：
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
git config --global init.defaultBranch main
git config --global core.autocrlf true
git config --global core.safecrlf true
git config --global core.quotepath false
git config --global color.ui true
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm commit
git config --global alias.lg "log --oneline --graph --all --decorate"
git config --global credential.helper manager
macOS环境：
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
git config --global init.defaultBranch main
git config --global core.autocrlf input
git config --global core.quotepath false
git config --global color.ui true
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm commit
git config --global alias.lg "log --oneline --graph --all --decorate"
git config --global credential.helper osxkeychain
Linux环境：
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
git config --global init.defaultBranch main
git config --global core.autocrlf input
git config --global core.quotepath false
git config --global color.ui true
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm commit
git config --global alias.lg "log --oneline --graph --all --decorate"
git config --global credential.helper cache
最后一条建议：配置完成之后，用一个空目录做一次完整的流程测试——git init、创建文件、git add、git commit、推送远程、修改文件、提交、再拉取。全部跑通，说明这台机器的git环境是健康的。别等到真开工了才遇到问题，那时候再排查环境问题就太耽误事了。git这种工具的配置属于"一次配好，长期受益"的类型，前期花十几分钟把基础打牢，后面省下来的时间远远不止这些。