1. 环境准备：先把Git装好再谈其他
不管你是刚入行的前端新人，还是写了几年业务代码的老兵，换台新电脑或者刚接手一台公司分配的机器，第一件事往往不是装IDE，而是把Git环境拉起来。这个工具现在已经是开发者的基础设施，没有它，代码协作基本寸步难行。
1.1 不同系统下的Git安装方式
Windows用户建议直接去官网下载安装包，一路默认配置点到底就行。安装过程中有几个选项值得留意：组件选择默认即可，但“默认编辑器”别选Vim，如果你不熟悉Vim的操作方式，后续写提交信息时会非常难受，我一般选Visual Studio Code或Notepad++。
macOS用户就比较省事了，只要机器上装了Homebrew，一条命令搞定：
brew install git不过这里有个细节：macOS自带的Git（通过git --version能查到的系统自带版本）通常比较老，虽然能用，但某些新版Git的功能和bug修复是没有的。所以强烈建议统一用Homebrew安装的版本，安装完成后可以执行which git确认当前指向的是/usr/local/bin/git而不是/usr/bin/git。
Linux发行版各自有包管理器，Ubuntu和Debian系用：
sudo apt update sudo apt install gitCentOS或Fedora这类RHEL系则用：
sudo yum install git1.2 用终端还是图形客户端
很多新手一上来就装Git小乌龟（TortoiseGit）或者IDE内置的Git面板，觉得有界面方便。这个选择我不反对，图形界面确实是很好的辅助工具，但强烈建议至少把终端里的Git命令练熟——因为有时候你拿不到图形界面的操作权限，或者服务器上只有终端环境，这时候只能靠命令。
而且说实话，终端命令并没有想象中难记。常用的来来去去就那么十条：status、add、commit、push、pull、clone、branch、checkout、merge、log。今天就先把这些基本功练扎实。
1.3 安装完成的验证方式
装完之后不要急着去配置，先验证一下环境变量是否生效。打开终端（Windows可以按Win+R输入cmd，或者直接用PowerShell），执行：
git --version如果输出类似于git version 2.40.1.windows.1的内容，说明安装成功了。有时候会遇到“git不是内部或外部命令”的报错，这种情况90%是环境变量没配好，但Windows的Git安装包一般会自动写入环境变量，极少出现这种问题。真遇到了，去“系统属性-环境变量-Path”里检查一下有没有Git的bin目录路径。
2. 全局配置：这一步藏着最多人忽略的坑
Git安装好之后不能直接干活，得先告诉它“你是谁”。这一步很多人会跳过，或者随便写一个名字和邮箱。我当时刚接触Git的时候也觉得这玩意儿无所谓，后来给开源项目提Pull Request时才意识到：提交作者信息写错了，改起来麻烦得要命。
2.1 user.name和user.email到底影响什么
每次执行git commit时，Git会把当前配置的用户名和邮箱作为作者信息写入这次提交记录。这些信息会永久留在提交历史里，会显示在Gitee或GitHub的提交列表上。如果提交信息不正确，哪怕代码写得再漂亮，别人也不知道这个提交到底是谁做的。
配置命令相当简单：
git config --global user.name "你的名字" git config --global user.email "你的邮箱"这里有一个容易踩的细节：注册代码托管平台时用的邮箱和Git配置的邮箱最好保持一致。如果你在Gitee上绑定的邮箱是A，但Git里配置的邮箱是B，提交记录不会被关联到你的账号上——提交头像不会显示，贡献度也不会被统计。别问我怎么知道的，都是泪。
2.2 除了身份信息，这三个全局参数也建议一起配好
第一个是默认分支名。老版本Git创建仓库时默认分支叫master，但新的Git版本已经开始默认使用main作为初始分支。为了统一，建议显式指定：
git config --global init.defaultBranch main第二个是换行符处理。Windows和Linux/macOS的换行符不同，Windows用CRLF，Linux/macOS用LF。如果不做处理，在文件被多次跨平台修改后，Git会疯狂提示“LF will be replaced by CRLF”之类的警告，严重的还会导致整个文件被判定为改动。Windows用户建议设置：
git config --global core.autocrlf truemacOS/Linux用户则设置：
git config --global core.autocrlf input第三个是提交信息编辑器。前面提到了，如果你不想每次提交信息时陷入Vim无法退出的窘境，就换掉它：
git config --global core.editor "code --wait"2.3 检查配置是否生效
配置完可以用这条命令查看全部内容：
git config --list如果内容太多，也可以只看某个单独项：
git config --global user.name配置是分层的，--global写入的是当前用户的全局配置，存在用户主目录下的.gitconfig文件里；还有一种--local配置只对当前仓库生效。如果全局配置和仓库配置冲突时，仓库配置优先。
3. 初始化本地仓库并完成首次提交
配置好了身份信息，接下来就进入正题了：怎么把本地一个普通文件夹变成一个Git仓库。
3.1 目录结构设计和git init的正确姿势
在实际开发中，很少有人会对整个磁盘根目录执行git init，通常是为项目单独建一个文件夹，然后在这个项目根目录下初始化仓库。我见过不少新手把git init执行在C:\Users\用户名这种目录下，结果后续操作全是“Not a git repository”或者把一堆无关文件都纳入了版本控制。
正确的做法是：
mkdir my-project cd my-project git init执行后Git会返回Initialized empty Git repository in ...，此时这个目录就已经是仓库了。这里顺带解释一下git init背后做了什么：它在当前目录下创建了一个隐藏的.git文件夹，这个文件夹里存放着Git所需要的全部元数据——对象数据库、引用、配置、钩子脚本等。不要动这个文件夹里的东西，否则仓库就废了。
3.2 理解工作区、暂存区和版本库
初学Git最容易卡住的就是这三个概念。我先用大白话解释一遍：
- 工作区：就是你电脑上实际看到的文件目录，你在这里写了代码、改了文件。
- 暂存区：一个中间缓冲区，用
git add把工作区的改动放进去。 - 版本库：最终提交后，文件会生成一个不可变的版本快照，存在这里。
打个比方，暂存区就像超市购物车。你在货架上（工作区）逛，把想买的东西（改动文件）放进购物车（暂存区），最后去收银台结账（执行git commit），结账完这单交易才算正式产生。
3.3 首次提交：从创建一个README开始
我习惯初次提交只做一件事——创建一个README文件并提交。这样后续的提交历史从第一条开始就是清晰的。
echo "# 我的第一个Git项目" >> README.md git add README.md git commit -m "Initial commit: 添加项目说明文件"这里解释一下git add和git commit的分工：git add把README.md从工作区添加到暂存区，git commit把暂存区的内容永久的写入版本库，生成一个提交对象。如果你修改了多个文件但只想提交部分文件，完全可以只add其中几个，这给了开发者在提交前精准选择改动内容的自由度。
commit之后，用git status查看，会显示工作区“clean”，说明当前没有待提交的改动。再用git log --oneline能看到刚创建的提交记录。
3.4 提交信息怎么写才专业
提交信息是别人了解你这次改动的重要途径。我见过太多“update”“修改”“test”这种毫无信息量的提交信息，事后回查代码时完全想不起来当时干了啥。
一份合格的提交信息通常包含：类型前缀（feat表示新功能、fix表示修bug、docs表示文档改动、refactor表示重构）、简要描述改动内容、如果有必要还可以在正文里写详细说明。例如：
git commit -m "fix: 修复登录接口在高并发下返回500的问题"如果一次提交后发觉信息写错了，趁没推到远程仓库之前可以直接修改：
git commit --amend这个命令会把当前的改动合并到上一次提交中，并重新编辑提交信息。但要注意：如果这个提交已经推到远程，并且有多人协作拉取过，不要用amend，否则会造成历史分叉，让同事很难受。
4. 关联远程仓库：Gitee/GitHub从新建到push
本地仓库建好只是第一步，真正让代码“活”起来的是把它推到远程仓库。这一步不少新手会卡住，尤其是SSH密钥配置那一块。
4.1 在托管平台新建远程仓库
以Gitee或GitHub为例，登录后在页面右上角找到“新建仓库”，填一个名称，选择公开或私有，建议同时勾选“初始化仓库”时创建一个README——但如果你本地已经建好了仓库，就不要勾选，否则后面push时会遇到远程和本地内容不相关导致的冲突。
命名建议和本地项目文件夹保持一致，比如本地叫my-project，远程仓库也叫my-project，这样团队合作时不用猜来猜去。
4.2 选择HTTPS还是SSH
这是一个绕不开的选择。HTTPS方式简单直观，push时输入账号密码（或者令牌）就能用，适合偶尔操作的个人项目。SSH方式需要在本地生成密钥，然后把公钥配置到托管平台，后续操作免输入账号密码，更安全，适合长期维护的项目。
学校或公司的内部GitLab一般两种方式都支持，但生产环境我更推荐SSH。理由有以下几点：不用每次输入密码；密钥对安全性更高；即使密码泄露，别人也无法直接凭借密码push代码——前提是平台开启了SSH访问。
4.3 SSH密钥生成与配置全流程
生成密钥的命令不复杂：
ssh-keygen -t ed25519 -C "你的邮箱"一路回车即可。它在~/.ssh目录下生成两个文件：id_ed25519是私钥，绝对不要泄露给别人；id_ed25519.pub是公钥，需要填到托管平台上。
用cat ~/.ssh/id_ed25519.pub查看公钥内容，复制整段内容，到Gitee或GitHub的“设置-SSH公钥”页面粘贴保存。
有些老教程还会推荐-t rsa -b 4096参数，但ed25519算法更安全更快，新项目建议用这个。如果是公司内部的老旧Git服务器，可能存在不支持ed25519的情况，那时候再用rsa也不迟。
测试是否配置成功：
ssh -T git@gitee.com如果返回欢迎信息，说明SSH链路已经通了。
4.4 添加远程仓库并推送代码
回到本地仓库目录，执行：
git remote add origin git@gitee.com:用户名/my-project.git这里的origin是远程仓库的别名，是业界约定俗成的默认名称，也可以叫别的名字，但没必要特立独行。git remote add不会真正连接远程，只是做了个本地映射。
接着把本地代码推到远程：
git push -u origin main-u参数的意思是“设置上游分支”，它会将本地的main分支与远程的main分支建立关联。以后在当前分支下，直接执行git push或git pull就能推拉代码，不用再写完整命令。
4.5 远程关联的验证与常见提醒
推送成功后，拷到浏览器打开远程仓库页面，就能看到代码已经上去了。可以用git remote -v查看当前关联了哪些远程地址，还能顺便检查有没有拼错仓库路径。
有一点想提醒：首次push时需要确认远程仓库是空的。如果远程已经存在了文件（比如平台自动生成的README），本地推送就会被拒绝，提示类似“failed to push some refs”。这时候要么先git pull origin main --rebase拉取远端内容合并，要么把远程仓库删了重建——选择哪种方式，取决于你本地代码是否还有保留价值。
5. 常用问题排查与提效技巧
5.1 高频报错与解决方法速查
| 报错信息 | 原因 | 解决方法 |
|---|---|---|
| fatal: Not a git repository | 当前目录不是Git仓库或不在仓库子目录 | 执行git init或cd到仓库根目录 |
| fatal: remote origin already exists | 已经关联过远程仓库 | git remote set-url origin 新地址或先git remote remove origin |
| Permission denied (publickey) | SSH公钥未配置或不对 | 检查~/.ssh下的公钥是否已添加到平台 |
| fatal: refusing to merge unrelated histories | 本地和远程仓库存在两套独立历史 | git pull origin main --allow-unrelated-histories |
| LF will be replaced by CRLF | 跨平台换行符分歧 | 按上文设置core.autocrlf |
| Updates were rejected because the remote contains work | 远程有本地没有的提交 | 先git pull --rebase合并再push |
最后一条“Updates were rejected”出现频率尤其高，很多新手第一反应是强推：git push -f。这个操作我极其不建议，尤其是在共享分支上，强推会覆盖别人的提交记录，影响很恶劣。正确方式是先拉取远程的更新，解决冲突后再推送。
5.2 让日常操作效率翻倍的小技巧
git status虽然是使用频率最高的命令，但每次输入都比较费手指，可以设置一个简短的别名：
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 st就能替代git status。
另一个很实用的是.gitignore文件。建仓库之初就应当加上，把系统文件、依赖目录、编译产物、敏感配置排除在版本控制之外。比如Node.js项目通常要忽略node_modules，Python项目要忽略__pycache__和.venv。一个简单的node_modules/写在文件里，就能让本地状态干净好多。
5.3 分支创建与提交规范的心态建设
提到分支，很多初学者会觉得复杂：“我是不是要等熟练了再用分支？”其实恰恰相反，正是因为是新手，才要更早养成用分支的习惯。
工作流不需要一开始追求复杂的Git Flow模型，先掌握最简单的特性分支就行：
git checkout -b feature/login # 在分支上开发并提交 git push -u origin feature/login这个操作相当于给代码工作开了一条新的时间线，主分支main保持稳定可用，功能分支合并之前可以放心大胆地改。等代码测完没问题了，再合并回主分支。哪怕出错也只需要处理分支上的问题，不会影响主干。
5.4 还有一些容易被忽略的好用命令
如果一个文件被误删了，但之前已经提交过版本，用git checkout -- 文件名可以恢复（新版本也可以用git restore）。如果误提交了一次改动，想撤销本次提交但保留文件内容，使用git reset --soft HEAD~1。
查看某行代码是谁在什么时候写的，最优雅的方式是：
git blame 文件名这在排查问题、向同事请教某段代码时特别好用，能精准定位到提交人而不需要到处问。
这些命令都不难，真正难的是养成“频繁提交、每个提交只做一件事”的习惯。我个人的体感是：提交粒度越细，日后定位问题越省力，回退代码的操作也越安全。
