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可以按WinR输入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用CRLFLinux/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 --wait2.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 gitgitee.com如果返回欢迎信息说明SSH链路已经通了。4.4 添加远程仓库并推送代码回到本地仓库目录执行git remote add origin gitgitee.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 originPermission denied (publickey)SSH公钥未配置或不对检查~/.ssh下的公钥是否已添加到平台fatal: refusing to merge unrelated histories本地和远程仓库存在两套独立历史git pull origin main --allow-unrelated-historiesLF will be replaced by CRLF跨平台换行符分歧按上文设置core.autocrlfUpdates 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_modulesPython项目要忽略__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 文件名这在排查问题、向同事请教某段代码时特别好用能精准定位到提交人而不需要到处问。这些命令都不难真正难的是养成“频繁提交、每个提交只做一件事”的习惯。我个人的体感是提交粒度越细日后定位问题越省力回退代码的操作也越安全。