很多人第一次接触 Git都是在搜索框里输入“Git 教程”然后被一堆名词术语劝退。我也经历过那个阶段刚入职时同事让我把代码推到仓库里我当时连add和commit都分不清硬着头皮敲了几个命令结果把别人的分支搞得一团乱至今想起来还觉得脸红。后来带过不少新人发现大家踩的坑都差不多。所以这篇“2026年最新最快上手 Git 教程”我不打算跟你聊那些晦涩的内部原理而是直接从我这几年的实操经验出发带你用最快速度跑通最核心的工作流。这篇文章适合谁刚入行的开发者、从 SVN 或 FTP 传代码时代转过来的老手、以及那些“用了很久 Git 但全靠复制粘贴”的朋友。我会把最常见的操作、最实用的命令、以及我在真实项目里踩过的坑全部拆开讲清楚。保证你从头到尾读完能独立完成从初始化仓库到解决合并冲突的全部流程。1. 先理解 Git 到底在干什么1.1 一句话解释版本控制这件事想象你在写一份方案文档改到第三版的时候领导说“还是第一版好”。如果文件名叫方案终版3.doc你还能找回来但如果改了无数次又没留备份就只能拍大腿。Git 干的事情就是给每次修改拍一张快照让你随时能回到任何历史版本。这个“快照”不是把整个文件复制一份放在那儿而是记录这次相对上次改动了什么。Git 用一个.git隐藏文件夹来存放所有这些历史记录。你的项目代码本身加上这个.git文件夹里的所有历史合起来才是一个完整的 Git 仓库。1.2 2026年的今天为什么“快速上手”反而更难了这几年 Git 工具链变化很大。以前装个客户端配个 TortoiseGit 就能玩一天现在大家更习惯命令行加 IDE 内置工具的结合。新出的工具、新的认证方式、新的分支策略让新手不知道该听谁的。我给新人的建议从来都是先学命令行再学图形界面。原因很简单命令行中的每个命令就是 Git 的一个核心概念你敲一遍git add、git commit就会对“暂存区”“提交”这些词有肌肉记忆。图形界面把一切都隐藏起来了反而让你不知所措。而且去网上的求助帖、AI 工具里找参考得到的也基本都是命令行代码。1.3 最快上手路径只学一套核心闭环我不推荐你把官方文档从头翻到尾。资料越全你越焦虑。2026年一个普通开发者日常用到的 Git 命令其实只有十几个。把它们串成一个闭环你就能应付大多数工作场景建立仓库init或clone写代码后提交add、commit查看状态与历史status、log开分支干活branch、checkout、switch与远程同步pull、push、fetch合并代码merge、rebase可后补后悔药restore、reset、revert这套流程跑顺主流工作流里八成以上的操作你都覆盖了。下面每一节我都按这个闭环来讲。2. 从零开始安装与初始化仓库2.1 不同系统下的安装方式这一步没有太多花活但有两个细节容易让人卡住。Windows 用户我建议直接去 Git 官网下载安装包然后一路默认。有一个选项需要注意默认编辑器建议选 Notepad 或 VS Code而不是自带的 Vim。如果选了 Vim后面提交时不小心进入编辑界面会把很多人吓一跳因为你不知道要怎么保存退出。虽然只影响提交信息的编辑但体验完全不一样。macOS 用户分两种如果你装了 Homebrew一条brew install git搞定没装的话可以直接在官网下载 dmg 安装包或者通过 Xcode 的命令行工具间接安装后者会在你首次使用git命令时自动弹窗提示安装。Linux 就很简单了以 Ubuntu 系的 Debian 为例安装sudo apt update sudo apt install git -y安装完在终端里运行git --version能输出版本号就说明成功。如果显示的是git: command not found那可能是安装过程出错或者没把路径配好重装一次基本都能解决。2.2 全局配置与换行符问题Git 装好后你首先要告诉它“你是谁”否则它不会让你提交代码。在下边命令中填入你自己的用户名和邮箱git config --global user.name Your Name git config --global user.email youexample.com这个邮箱最好和你代码托管平台比如某代码托管平台的注册邮箱保持一致因为每次提交都会把你的名字和邮箱写进历史别人看提交记录时就能一眼认出你。接下来避坑的关键一步Windows 用户建议全局配置一下换行符处理方式否则后续拉取代码时很容易出现“整个文件都显示被修改”的诡异问题。原因在于 Windows 的换行符是 CRLF而 Linux/macOS 是 LFGit 需要帮你做自动转换。配置命令如下git config --global core.autocrlf true如果你团队里有人用 Mac有人用 Windows甚至还有人用 Linux 服务器这步配置务必做好。不然代码啥都没改git diff却显示几千行变动找 Bug 能把你心态搞崩。2.3 新建项目仓库本地初始化现在进入一个空目录也可以新建一个目录放项目代码然后执行git init这个命令会在当前目录下悄悄创建一个.git子目录。从此以后这个普通文件夹就变成了一个 Git 仓库README 也好、代码也好所有文件都被 Git 盯着了。比如我用test-git这个目录作演示初始化后运行ls -a你能看到.git文件夹。看不到也没关系说明你可能用了普通ls而不是ls -a或者文件资源管理器默认不显示隐藏项目。如果你的项目原来就在某个代码托管平台上那就不是init了而是用clone拉下来。这个我们后面细说。3. 核心工作流详解从修改代码到提交记录3.1 工作区、暂存区、版本库的概念网上很多教程喜欢画三张图来解释这三个区域我这次直接用一句生活化的话来比喻工作区你的办公桌文件随便摆。暂存区你手里的托盘把要交给老板的东西先放上去。版本库老板的档案柜放上去的东西永久留档前提是有人翻查。也就是说你在工作区里正常写代码这是你的私人空间。等你觉得写完了就用git add把文件放到暂存区让它出现在待提交清单里最后用git commit一股脑丢进版本库形成一条不可磨灭的提交记录。为什么要搞这么复杂直接保存不行吗想象你在一个项目里改了十个文件但只有三个文件和当前这个任务有关。如果你一股脑全提交了以后想找线索会很痛苦。有了暂存区你就可以精准地挑出这三个文件提交剩下的七个继续在桌面摊着。3.2 最常用的四个命令实操在test-git目录里新建一个文本文件hello.txt然后依次执行git status git add hello.txt git commit -m init: add hello.txt git status每一步都看一下输出结果你会直观地感受到文件状态从untracked变成changes to be committed最后变成nothing to commit的过程。这里有个新手必学的小技巧提交信息commit message建议不要写“update”这种没营养的话而是用一句话说清楚“我干了什么”。比如fix: 修复登录页在移动端的跳转问题。将来自己回头翻代码或者帮别人 review都省力太多了。提交格式习惯模版feat: 新增用户注册功能 fix: 修复订单金额计算错误 docs: 更新 README 文档 refactor: 重构支付回调逻辑“feat”和“fix”是目前开源社区最常见的前缀。不用背但可以参考着用。3.3 查看历史Git log 和它的花式玩法提交了几次之后想看历史就像翻微信聊天记录一样简单git log你会看到一串黄色乱码其实是哈希值比如commit 9f3a2b1c...就是每次提交的唯一身份证号。上方写着作者、日期和提交信息。想看精简版git log --oneline每一行只显示一个提交的 ID 前几位和提交信息一目了然。如果觉得时间线太乱回车之后按q退出查看状态。还有一个我经常用的命令git log --graph --all --decorate --oneline。它会用字符画画出一个分支走向图帮你快速理清各分支之间的关系。为了省事我给它起了个短别名怎么配置别名见后面的“体验优化”部分。3.4 忽略文件让 Git 别管某些内容写代码的时候总有些文件不想被 Git 追踪比如编译生成的node_modules、本地的.env配置、日志文件、IDE 配置目录等。你可以在仓库根目录建一个.gitignore文件把不想管的文件写进去node_modules/ *.log .env .DS_Store我见过很多新手不建.gitignore结果把装有数据库密码的.env文件直接推送到远程仓库了酿成安全事故。所以强烈建议项目一开始就建好这个文件至少把.env、密钥文件、构建产物这三类东西先放进去。如果你用的是语言官方脚手架比如各类前端脚手架、后端框架工具生成的项目本身就会自带.gitignore别删掉它就对了。4. 分支一人一条平行线4.1 分支是干什么用的假设你在主线上开发新功能改到一半突然有一个线上紧急 Bug 要立刻修。如果不搞分支你就得把自己改了一半的半成品代码和修 Bug 的代码混在一起十分尴尬。分支的思路相当于从主干上拉出一条平行线你在平行线上怎么折腾都不影响主线等彻底开发完再把它合并回主线。这么做的好处是团队协作不再互相干扰坏处是合并冲突不知道该怪谁。但这是目前绝大多数现代开发团队的标准工作方式值得你花时间好好理解。4.2 快速创建与切换传统命令是git branch加git checkout现在新版 Git 更推荐用git switch这类新命令对新人更好记。git branch feature-a git switch feature-a第一行创建一个新分支feature-a第二行切过去。更快的写法是直接合并成git switch -c feature-a创建加切换一步到位。想知道当前在哪个分支看终端提示符是一个方法运行git branch --list也会列出全部本地分支当前分支前会带*号。例如* main feature-a这里注意一个常见认知误区很多新人以为多分支就等于多副本每个分支独立存一份全部文件。其实不是Git 只是记录“分叉点”和“变化量”所以创建分支非常轻量随便开几十个也不心疼。4.3 合并操作与冲突解决分支开发完要并回主线。以main分支合并feature-a为例。git switch main git merge feature-a如果两边改的文件“井水不犯河水”Git 会自动完成合并并生成一条合并提交记录。如果两边改了同一个文件的同一处位置Git 就不知道该听谁的会停下来说“冲突了”让你自己定。冲突长什么样打开冲突文件你会看到类似这样的标记 HEAD 这里是 main 分支上的内容 这里是 feature-a 分支上的内容 feature-a遇到这种情况不要慌。手动去把到之间的内容改成一个最终版本删掉那些标记符号即可。改完记得执行git add 冲突文件 git commitGit 就会认为你已经解决了冲突并保留这次处理结果。注意不要直接复制别人的冲突解法一定要理解双方逻辑否则很容易留下逻辑 Bug。4.4 从个人经验谈分支策略这里补充一点我的实操教训。我刚工作那会儿团队用的是“一个 main 走到黑”的模式所有人都直接往main上推。结果经常出现线上突然多了半个功能、同事拉代码拉下来就报错的情况。后来转成“功能分支 合并前必须走评审”的模式日子才清静许多。具体策略不唯一但可以给个参考main分支永远保持可发布状态。功能分支从main新建命名叫feature/用户注册。Bug 修复分支从对应版本标签新建命名叫hotfix/登录崩溃。别一开始就纠结用 Git Flow 还是 GitHub Flow。先把“分支合并”玩熟后面再按团队规范调整完全来得及。5. 与远程仓库协作push、pull 与 PR5.1 本地仓库和远程仓库的关系远程仓库就是一个放在服务器上的 Git 仓库可以理解成公共档案柜。你本地的.git是你的私人档案柜。你要让同事看到你的代码就得把本地提交推送到远程仓库去。同理你想拿到同事的新代码就从远程仓库拉下来。以前很多教程会教你先git add remote添加地址现在其实不用了因为大多数项目都是先在某个代码托管平台上建好空仓库再在本地clone下来或者执行一段向导提示命令远程地址就已经配好了。执行git remote -v可以看到当前配置的远程地址列表。5.2 认证方式的变化从账号密码到访问令牌2026年的今天绝大多数代码托管平台都不再支持直接在终端输入账号密码来推送。取而代之的是以下两种主流方式SSH Key 方式先在本地生成一对公钥和私钥公钥放在托管平台的后台私钥留在自己电脑。每次推送时 Git 通过 SSH 协议自动校验身份。这是我最推荐的方式配置好之后几乎无感以后都不用重复输入密码。访问令牌方式在平台后台生成一个有期限的令牌把它当密码用。生成 SSH Key 的命令ssh-keygen -t ed25519 -C youexample.com一路回车也可以给私钥设个密码安全性更好然后查看公钥cat ~/.ssh/id_ed25519.pub把输出的那串内容复制到托管平台后台“SSH Keys”设置里即可。5.3 常用远程操作闭环假设你在某个托管平台上创建了一个空仓库复制了它的 SSH 地址然后git clone gitexample.com:你的用户名/你的项目.git cd 你的项目这样本地仓库和远程仓库就连上了默认会有一个叫origin的远程命名和你切换到的默认分支多数是main。你写完了提交之后推送到远程git push中途如果你的分支还没设上游Git 会提示你用git push --set-upstream origin 分支名照着执行就行。以后同一条分支就直接git push了。拉取远程的更新git pullpull的本质是fetch抓取远程更新merge把远程分支合并到本地分支。也可以分开用这么做的好处是能先看看远程有什么变化再决定怎么处理。比如git fetch origin git log --oneline HEAD..origin/main git merge origin/main这个操作在多人协作项目里很实用因为它让你在合并之前先看看到底会多出哪些提交。拉取时如果有冲突解决方式和前面“分支合并冲突”一模一样。5.4 Pull Request代码评审的标配流程在开源社区或公司主流流程里通常不是自己直接往main分支推而是把分支推到远程之后在平台网页上发起一个合并请求Pull Request简称 PR让团队里其他人帮你审查代码。等审查者点击“合并”你的代码才真正进入主线。这里有一个关键动作推送前务必先拉一次最新代码把目标分支的最新状态合并进你的功能分支尽可能把合并冲突消灭在发起 PR 之前。否则审查者看到 PR 里有大量冲突标记第一印象就会很差。6. 撤销和回滚给每个操作留好后悔药6.1 文件改动回退restore 与 checkout很多人学会提交却不会改错导致一旦写错代码就慌。这里先区分几种场景。场景一你刚改了工作区文件还没add想放弃改动。执行git restore 文件名未跟踪的新文件用这个命令是删不掉的可以用git clean -fd清理未跟踪文件。但这命令会删文件使用前先看清楚影响。如果你不小心把它改成git restore .所有被追踪文件的改动全没了回不来的。改之前拿git status确认一下。场景二你已经git add放进暂存区了不想把文件放进这次提交。执行git restore --staged 文件名这个命令只是把文件从暂存区“撤下来”你的改动内容还在不算丢。6.2 提交记录回退reset 与 revert如果已经提交了才发现代码写错了你有两种不同的后悔方式。git reset是“时间回溯”可以把当前分支移动到之前的某个提交git reset --hard HEAD~1这个命令会把当前分支回退到上一个提交同时清空工作区的改动。危险指数极高使用前一定确认没有你想要保留的代码。另一个更温和的形式是git reset --soft HEAD~1它只撤销提交记录但会把代码改动保留在暂存区。适合“提交信息写错了”或者“还有想法要继续改”的情况。git revert则相反它是“生成一个反向提交来抵消某个旧提交”。比如说线上代码出 Bug你定位到是某次旧提交引入的你并不想把整个项目时间线倒退到那次提交之前因为中间可能还有一堆新功能。你只需要生成一个反向变化把那次提交的改动抵消掉git revert 那个提交的ID这种方式不会改写历史更适合已经推送到远程并被别人拉取过的分支。一句话总结本地还没推送用 reset 随意折腾已推送且多人协作用 revert 保守抵消。6.3 分支误删与丢失提交的恢复曾经有一次我误删了一个分支当时感觉天都塌了。后来发现 Git 的提交对象并没有立刻被销毁只是变得“悬空”了只要记录下那个提交的哈希值就能把它找回来。误删分支后先看操作日志git reflogreflog会列出 HEAD 指针最近的移动记录里面能看到你误删分支前指向的提交 ID。然后基于这个 ID 直接切回去git switch -c 新分支名 那个提交ID只要时间不长绝大多数情况下都能找回。所以遇到误删操作第一反应不是重写代码而是查reflog。这也是我反复跟新人强调的一点Git 比你想象的更“宽容”但也别因此乱用高风险命令。7. 高频命令优化与问题排查速查7.1 配置别名与简化日常操作一天到晚敲git status和git log --oneline其实挺累的Git 允许配置别名。我常用的几行配置git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.lg log --graph --all --decorate --oneline配完之后git st等价于git statusgit lg就是超好用的分支图命令。新同事看到我敲得飞快其实只是比他们少打了几个字母。7.2 我用 git 都遇到过哪些坑遇到问题不可怕怕的是不知道去哪查原因。下面这些是个按“症状”来查的速查表。症状可能原因解决办法提交时提示需要配置 user.name没做全局配置执行git config --global user.name和user.emailgit push被拒绝non-fast-forward本地落后于远程先git pull再解决冲突或先git fetch后merge拉取后大量文件显示已修改换行符配置不一致设置core.autocrlf true后重新拉取或转换误提交了不想提交的文件暂存区包含了多余内容用git restore --staged撤出然后修改.gitignore想合并的分支实际上没变化分支可能已经合并过用git branch --merged查看文件被删除但没提交工作区删除了文件想恢复用git restore 文件名想正式删除用git rm推送时报权限错误SSH Key 或令牌失效检查ssh -T连接测试是否通过重新上传公钥7.3 新手最容易忽视的三个习惯我观察了身边很多同事总结出三个最容易吃亏的习惯第一提交前不检查。很多人的流程是闷头写代码写完直接git add .然后提交。加个.确实是全部包含的意思但也可能把调试日志、本地密钥、不必要的缓存全都提交进去。宁可每次git status和git diff多花一分钟也别给自己埋雷。第二推送到远程前不拉取最近代码。本地一个人在改远远没问题但只要团队有两个人你不拉代码就推送大概率会被拒绝又得慌慌张张去解决冲突。记住冲突最好在本地解决别等着在 PR 里暴露给所有人看。第三依赖图形界面导致不知道底层在干嘛。图形界面确实方便但如果你不清楚它背后执行的是什么命令出了问题根本无法排查。我的建议是日常操作可以用图形界面但至少要知道每个按钮对应哪条 Git 命令。7.4 一个提升幸福感的建议装个终端提示很多终端的命令行主题会直接显示当前分支名比如test-git (main)。但一些默认的终端环境没有这个功能导致你在哪个分支都靠猜。这里给两条路用各类主流 Shell 的提示符定制工具它能在终端右侧显示 Git 分支和当前文件状态。如果你喜欢轻量就用一个最简单的方案每天开始工作前先敲一遍git branch看一遍当前位置。虽然麻烦点但至少不会把功能提交到main上。当然如果你用 VS Code 等现代化编辑器左侧源代码管理面板会直接显示分支名、未暂存改动和暂存改动。点击对应按钮就能完成add、commit、push对于新手来说同样是很好的辅助。但请记住我之前的建议辅助工具可以帮你干得顺手但不能替代你理解底层命令。8. 最后分享一点我踩过坑后的个人体会我见过有人一上来就啃官方文档和底层原理结果啃了俩月还在纠结“Git 对象模型是什么”代码一步没推。也见过有人压根不看原理直接靠鼠标点按钮结果遇到一次删除冲突就整个仓库翻车。最理想的路径其实就是这条先跑通第 2 节到第 6 节的核心闭环建立起“工作区、暂存区、版本库、分支、远程”这几个最基本的心智模型然后在日常使用中遇到一个坑就加深一层理解等到你把merge和rebase的区别弄明白时你已经比相当一部分开发者强了。如果再让我带一个零基础的新人我会让他先把git reset --soft和git restore --staged这两个命令背下来。因为一个管提交后悔一个管暂存后悔平时真的天天用到。另外想提醒你的是不要有事没事就想着重写历史。虽然git rebase -i看着很牛但对协作中的分支大规模改写提交历史往往是灾难现场。我自己的习惯是只有在我确定这个分支只有我一个人在用时才会用rebase整理提交。否则一律用merge简单、诚实、不出幺蛾子。操作之前心里默念三遍先看状态先看状态先看状态。几乎所有事故都是因为在执行命令前没有用git status确认当前头在哪里、哪些文件有变动。把这件事变成肌肉记忆你在 Git 上踩的坑会少掉一大半。看完这篇挑个目录实践一下把核心闭环跑通。那些还没讲到的高级技巧等你真正需要的时候再回来翻就好。 
长河君 · 2026/10/21 14:10:52 · 阅读 1.2k Git快速上手：核心命令详解与团队协作实操指南
很多人第一次接触 Git都是在搜索框里输入“Git 教程”然后被一堆名词术语劝退。我也经历过那个阶段刚入职时同事让我把代码推到仓库里我当时连add和commit都分不清硬着头皮敲了几个命令结果把别人的分支搞得一团乱至今想起来还觉得脸红。后来带过不少新人发现大家踩的坑都差不多。所以这篇“2026年最新最快上手 Git 教程”我不打算跟你聊那些晦涩的内部原理而是直接从我这几年的实操经验出发带你用最快速度跑通最核心的工作流。这篇文章适合谁刚入行的开发者、从 SVN 或 FTP 传代码时代转过来的老手、以及那些“用了很久 Git 但全靠复制粘贴”的朋友。我会把最常见的操作、最实用的命令、以及我在真实项目里踩过的坑全部拆开讲清楚。保证你从头到尾读完能独立完成从初始化仓库到解决合并冲突的全部流程。1. 先理解 Git 到底在干什么1.1 一句话解释版本控制这件事想象你在写一份方案文档改到第三版的时候领导说“还是第一版好”。如果文件名叫方案终版3.doc你还能找回来但如果改了无数次又没留备份就只能拍大腿。Git 干的事情就是给每次修改拍一张快照让你随时能回到任何历史版本。这个“快照”不是把整个文件复制一份放在那儿而是记录这次相对上次改动了什么。Git 用一个.git隐藏文件夹来存放所有这些历史记录。你的项目代码本身加上这个.git文件夹里的所有历史合起来才是一个完整的 Git 仓库。1.2 2026年的今天为什么“快速上手”反而更难了这几年 Git 工具链变化很大。以前装个客户端配个 TortoiseGit 就能玩一天现在大家更习惯命令行加 IDE 内置工具的结合。新出的工具、新的认证方式、新的分支策略让新手不知道该听谁的。我给新人的建议从来都是先学命令行再学图形界面。原因很简单命令行中的每个命令就是 Git 的一个核心概念你敲一遍git add、git commit就会对“暂存区”“提交”这些词有肌肉记忆。图形界面把一切都隐藏起来了反而让你不知所措。而且去网上的求助帖、AI 工具里找参考得到的也基本都是命令行代码。1.3 最快上手路径只学一套核心闭环我不推荐你把官方文档从头翻到尾。资料越全你越焦虑。2026年一个普通开发者日常用到的 Git 命令其实只有十几个。把它们串成一个闭环你就能应付大多数工作场景建立仓库init或clone写代码后提交add、commit查看状态与历史status、log开分支干活branch、checkout、switch与远程同步pull、push、fetch合并代码merge、rebase可后补后悔药restore、reset、revert这套流程跑顺主流工作流里八成以上的操作你都覆盖了。下面每一节我都按这个闭环来讲。2. 从零开始安装与初始化仓库2.1 不同系统下的安装方式这一步没有太多花活但有两个细节容易让人卡住。Windows 用户我建议直接去 Git 官网下载安装包然后一路默认。有一个选项需要注意默认编辑器建议选 Notepad 或 VS Code而不是自带的 Vim。如果选了 Vim后面提交时不小心进入编辑界面会把很多人吓一跳因为你不知道要怎么保存退出。虽然只影响提交信息的编辑但体验完全不一样。macOS 用户分两种如果你装了 Homebrew一条brew install git搞定没装的话可以直接在官网下载 dmg 安装包或者通过 Xcode 的命令行工具间接安装后者会在你首次使用git命令时自动弹窗提示安装。Linux 就很简单了以 Ubuntu 系的 Debian 为例安装sudo apt update sudo apt install git -y安装完在终端里运行git --version能输出版本号就说明成功。如果显示的是git: command not found那可能是安装过程出错或者没把路径配好重装一次基本都能解决。2.2 全局配置与换行符问题Git 装好后你首先要告诉它“你是谁”否则它不会让你提交代码。在下边命令中填入你自己的用户名和邮箱git config --global user.name Your Name git config --global user.email youexample.com这个邮箱最好和你代码托管平台比如某代码托管平台的注册邮箱保持一致因为每次提交都会把你的名字和邮箱写进历史别人看提交记录时就能一眼认出你。接下来避坑的关键一步Windows 用户建议全局配置一下换行符处理方式否则后续拉取代码时很容易出现“整个文件都显示被修改”的诡异问题。原因在于 Windows 的换行符是 CRLF而 Linux/macOS 是 LFGit 需要帮你做自动转换。配置命令如下git config --global core.autocrlf true如果你团队里有人用 Mac有人用 Windows甚至还有人用 Linux 服务器这步配置务必做好。不然代码啥都没改git diff却显示几千行变动找 Bug 能把你心态搞崩。2.3 新建项目仓库本地初始化现在进入一个空目录也可以新建一个目录放项目代码然后执行git init这个命令会在当前目录下悄悄创建一个.git子目录。从此以后这个普通文件夹就变成了一个 Git 仓库README 也好、代码也好所有文件都被 Git 盯着了。比如我用test-git这个目录作演示初始化后运行ls -a你能看到.git文件夹。看不到也没关系说明你可能用了普通ls而不是ls -a或者文件资源管理器默认不显示隐藏项目。如果你的项目原来就在某个代码托管平台上那就不是init了而是用clone拉下来。这个我们后面细说。3. 核心工作流详解从修改代码到提交记录3.1 工作区、暂存区、版本库的概念网上很多教程喜欢画三张图来解释这三个区域我这次直接用一句生活化的话来比喻工作区你的办公桌文件随便摆。暂存区你手里的托盘把要交给老板的东西先放上去。版本库老板的档案柜放上去的东西永久留档前提是有人翻查。也就是说你在工作区里正常写代码这是你的私人空间。等你觉得写完了就用git add把文件放到暂存区让它出现在待提交清单里最后用git commit一股脑丢进版本库形成一条不可磨灭的提交记录。为什么要搞这么复杂直接保存不行吗想象你在一个项目里改了十个文件但只有三个文件和当前这个任务有关。如果你一股脑全提交了以后想找线索会很痛苦。有了暂存区你就可以精准地挑出这三个文件提交剩下的七个继续在桌面摊着。3.2 最常用的四个命令实操在test-git目录里新建一个文本文件hello.txt然后依次执行git status git add hello.txt git commit -m init: add hello.txt git status每一步都看一下输出结果你会直观地感受到文件状态从untracked变成changes to be committed最后变成nothing to commit的过程。这里有个新手必学的小技巧提交信息commit message建议不要写“update”这种没营养的话而是用一句话说清楚“我干了什么”。比如fix: 修复登录页在移动端的跳转问题。将来自己回头翻代码或者帮别人 review都省力太多了。提交格式习惯模版feat: 新增用户注册功能 fix: 修复订单金额计算错误 docs: 更新 README 文档 refactor: 重构支付回调逻辑“feat”和“fix”是目前开源社区最常见的前缀。不用背但可以参考着用。3.3 查看历史Git log 和它的花式玩法提交了几次之后想看历史就像翻微信聊天记录一样简单git log你会看到一串黄色乱码其实是哈希值比如commit 9f3a2b1c...就是每次提交的唯一身份证号。上方写着作者、日期和提交信息。想看精简版git log --oneline每一行只显示一个提交的 ID 前几位和提交信息一目了然。如果觉得时间线太乱回车之后按q退出查看状态。还有一个我经常用的命令git log --graph --all --decorate --oneline。它会用字符画画出一个分支走向图帮你快速理清各分支之间的关系。为了省事我给它起了个短别名怎么配置别名见后面的“体验优化”部分。3.4 忽略文件让 Git 别管某些内容写代码的时候总有些文件不想被 Git 追踪比如编译生成的node_modules、本地的.env配置、日志文件、IDE 配置目录等。你可以在仓库根目录建一个.gitignore文件把不想管的文件写进去node_modules/ *.log .env .DS_Store我见过很多新手不建.gitignore结果把装有数据库密码的.env文件直接推送到远程仓库了酿成安全事故。所以强烈建议项目一开始就建好这个文件至少把.env、密钥文件、构建产物这三类东西先放进去。如果你用的是语言官方脚手架比如各类前端脚手架、后端框架工具生成的项目本身就会自带.gitignore别删掉它就对了。4. 分支一人一条平行线4.1 分支是干什么用的假设你在主线上开发新功能改到一半突然有一个线上紧急 Bug 要立刻修。如果不搞分支你就得把自己改了一半的半成品代码和修 Bug 的代码混在一起十分尴尬。分支的思路相当于从主干上拉出一条平行线你在平行线上怎么折腾都不影响主线等彻底开发完再把它合并回主线。这么做的好处是团队协作不再互相干扰坏处是合并冲突不知道该怪谁。但这是目前绝大多数现代开发团队的标准工作方式值得你花时间好好理解。4.2 快速创建与切换传统命令是git branch加git checkout现在新版 Git 更推荐用git switch这类新命令对新人更好记。git branch feature-a git switch feature-a第一行创建一个新分支feature-a第二行切过去。更快的写法是直接合并成git switch -c feature-a创建加切换一步到位。想知道当前在哪个分支看终端提示符是一个方法运行git branch --list也会列出全部本地分支当前分支前会带*号。例如* main feature-a这里注意一个常见认知误区很多新人以为多分支就等于多副本每个分支独立存一份全部文件。其实不是Git 只是记录“分叉点”和“变化量”所以创建分支非常轻量随便开几十个也不心疼。4.3 合并操作与冲突解决分支开发完要并回主线。以main分支合并feature-a为例。git switch main git merge feature-a如果两边改的文件“井水不犯河水”Git 会自动完成合并并生成一条合并提交记录。如果两边改了同一个文件的同一处位置Git 就不知道该听谁的会停下来说“冲突了”让你自己定。冲突长什么样打开冲突文件你会看到类似这样的标记 HEAD 这里是 main 分支上的内容 这里是 feature-a 分支上的内容 feature-a遇到这种情况不要慌。手动去把到之间的内容改成一个最终版本删掉那些标记符号即可。改完记得执行git add 冲突文件 git commitGit 就会认为你已经解决了冲突并保留这次处理结果。注意不要直接复制别人的冲突解法一定要理解双方逻辑否则很容易留下逻辑 Bug。4.4 从个人经验谈分支策略这里补充一点我的实操教训。我刚工作那会儿团队用的是“一个 main 走到黑”的模式所有人都直接往main上推。结果经常出现线上突然多了半个功能、同事拉代码拉下来就报错的情况。后来转成“功能分支 合并前必须走评审”的模式日子才清静许多。具体策略不唯一但可以给个参考main分支永远保持可发布状态。功能分支从main新建命名叫feature/用户注册。Bug 修复分支从对应版本标签新建命名叫hotfix/登录崩溃。别一开始就纠结用 Git Flow 还是 GitHub Flow。先把“分支合并”玩熟后面再按团队规范调整完全来得及。5. 与远程仓库协作push、pull 与 PR5.1 本地仓库和远程仓库的关系远程仓库就是一个放在服务器上的 Git 仓库可以理解成公共档案柜。你本地的.git是你的私人档案柜。你要让同事看到你的代码就得把本地提交推送到远程仓库去。同理你想拿到同事的新代码就从远程仓库拉下来。以前很多教程会教你先git add remote添加地址现在其实不用了因为大多数项目都是先在某个代码托管平台上建好空仓库再在本地clone下来或者执行一段向导提示命令远程地址就已经配好了。执行git remote -v可以看到当前配置的远程地址列表。5.2 认证方式的变化从账号密码到访问令牌2026年的今天绝大多数代码托管平台都不再支持直接在终端输入账号密码来推送。取而代之的是以下两种主流方式SSH Key 方式先在本地生成一对公钥和私钥公钥放在托管平台的后台私钥留在自己电脑。每次推送时 Git 通过 SSH 协议自动校验身份。这是我最推荐的方式配置好之后几乎无感以后都不用重复输入密码。访问令牌方式在平台后台生成一个有期限的令牌把它当密码用。生成 SSH Key 的命令ssh-keygen -t ed25519 -C youexample.com一路回车也可以给私钥设个密码安全性更好然后查看公钥cat ~/.ssh/id_ed25519.pub把输出的那串内容复制到托管平台后台“SSH Keys”设置里即可。5.3 常用远程操作闭环假设你在某个托管平台上创建了一个空仓库复制了它的 SSH 地址然后git clone gitexample.com:你的用户名/你的项目.git cd 你的项目这样本地仓库和远程仓库就连上了默认会有一个叫origin的远程命名和你切换到的默认分支多数是main。你写完了提交之后推送到远程git push中途如果你的分支还没设上游Git 会提示你用git push --set-upstream origin 分支名照着执行就行。以后同一条分支就直接git push了。拉取远程的更新git pullpull的本质是fetch抓取远程更新merge把远程分支合并到本地分支。也可以分开用这么做的好处是能先看看远程有什么变化再决定怎么处理。比如git fetch origin git log --oneline HEAD..origin/main git merge origin/main这个操作在多人协作项目里很实用因为它让你在合并之前先看看到底会多出哪些提交。拉取时如果有冲突解决方式和前面“分支合并冲突”一模一样。5.4 Pull Request代码评审的标配流程在开源社区或公司主流流程里通常不是自己直接往main分支推而是把分支推到远程之后在平台网页上发起一个合并请求Pull Request简称 PR让团队里其他人帮你审查代码。等审查者点击“合并”你的代码才真正进入主线。这里有一个关键动作推送前务必先拉一次最新代码把目标分支的最新状态合并进你的功能分支尽可能把合并冲突消灭在发起 PR 之前。否则审查者看到 PR 里有大量冲突标记第一印象就会很差。6. 撤销和回滚给每个操作留好后悔药6.1 文件改动回退restore 与 checkout很多人学会提交却不会改错导致一旦写错代码就慌。这里先区分几种场景。场景一你刚改了工作区文件还没add想放弃改动。执行git restore 文件名未跟踪的新文件用这个命令是删不掉的可以用git clean -fd清理未跟踪文件。但这命令会删文件使用前先看清楚影响。如果你不小心把它改成git restore .所有被追踪文件的改动全没了回不来的。改之前拿git status确认一下。场景二你已经git add放进暂存区了不想把文件放进这次提交。执行git restore --staged 文件名这个命令只是把文件从暂存区“撤下来”你的改动内容还在不算丢。6.2 提交记录回退reset 与 revert如果已经提交了才发现代码写错了你有两种不同的后悔方式。git reset是“时间回溯”可以把当前分支移动到之前的某个提交git reset --hard HEAD~1这个命令会把当前分支回退到上一个提交同时清空工作区的改动。危险指数极高使用前一定确认没有你想要保留的代码。另一个更温和的形式是git reset --soft HEAD~1它只撤销提交记录但会把代码改动保留在暂存区。适合“提交信息写错了”或者“还有想法要继续改”的情况。git revert则相反它是“生成一个反向提交来抵消某个旧提交”。比如说线上代码出 Bug你定位到是某次旧提交引入的你并不想把整个项目时间线倒退到那次提交之前因为中间可能还有一堆新功能。你只需要生成一个反向变化把那次提交的改动抵消掉git revert 那个提交的ID这种方式不会改写历史更适合已经推送到远程并被别人拉取过的分支。一句话总结本地还没推送用 reset 随意折腾已推送且多人协作用 revert 保守抵消。6.3 分支误删与丢失提交的恢复曾经有一次我误删了一个分支当时感觉天都塌了。后来发现 Git 的提交对象并没有立刻被销毁只是变得“悬空”了只要记录下那个提交的哈希值就能把它找回来。误删分支后先看操作日志git reflogreflog会列出 HEAD 指针最近的移动记录里面能看到你误删分支前指向的提交 ID。然后基于这个 ID 直接切回去git switch -c 新分支名 那个提交ID只要时间不长绝大多数情况下都能找回。所以遇到误删操作第一反应不是重写代码而是查reflog。这也是我反复跟新人强调的一点Git 比你想象的更“宽容”但也别因此乱用高风险命令。7. 高频命令优化与问题排查速查7.1 配置别名与简化日常操作一天到晚敲git status和git log --oneline其实挺累的Git 允许配置别名。我常用的几行配置git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.lg log --graph --all --decorate --oneline配完之后git st等价于git statusgit lg就是超好用的分支图命令。新同事看到我敲得飞快其实只是比他们少打了几个字母。7.2 我用 git 都遇到过哪些坑遇到问题不可怕怕的是不知道去哪查原因。下面这些是个按“症状”来查的速查表。症状可能原因解决办法提交时提示需要配置 user.name没做全局配置执行git config --global user.name和user.emailgit push被拒绝non-fast-forward本地落后于远程先git pull再解决冲突或先git fetch后merge拉取后大量文件显示已修改换行符配置不一致设置core.autocrlf true后重新拉取或转换误提交了不想提交的文件暂存区包含了多余内容用git restore --staged撤出然后修改.gitignore想合并的分支实际上没变化分支可能已经合并过用git branch --merged查看文件被删除但没提交工作区删除了文件想恢复用git restore 文件名想正式删除用git rm推送时报权限错误SSH Key 或令牌失效检查ssh -T连接测试是否通过重新上传公钥7.3 新手最容易忽视的三个习惯我观察了身边很多同事总结出三个最容易吃亏的习惯第一提交前不检查。很多人的流程是闷头写代码写完直接git add .然后提交。加个.确实是全部包含的意思但也可能把调试日志、本地密钥、不必要的缓存全都提交进去。宁可每次git status和git diff多花一分钟也别给自己埋雷。第二推送到远程前不拉取最近代码。本地一个人在改远远没问题但只要团队有两个人你不拉代码就推送大概率会被拒绝又得慌慌张张去解决冲突。记住冲突最好在本地解决别等着在 PR 里暴露给所有人看。第三依赖图形界面导致不知道底层在干嘛。图形界面确实方便但如果你不清楚它背后执行的是什么命令出了问题根本无法排查。我的建议是日常操作可以用图形界面但至少要知道每个按钮对应哪条 Git 命令。7.4 一个提升幸福感的建议装个终端提示很多终端的命令行主题会直接显示当前分支名比如test-git (main)。但一些默认的终端环境没有这个功能导致你在哪个分支都靠猜。这里给两条路用各类主流 Shell 的提示符定制工具它能在终端右侧显示 Git 分支和当前文件状态。如果你喜欢轻量就用一个最简单的方案每天开始工作前先敲一遍git branch看一遍当前位置。虽然麻烦点但至少不会把功能提交到main上。当然如果你用 VS Code 等现代化编辑器左侧源代码管理面板会直接显示分支名、未暂存改动和暂存改动。点击对应按钮就能完成add、commit、push对于新手来说同样是很好的辅助。但请记住我之前的建议辅助工具可以帮你干得顺手但不能替代你理解底层命令。8. 最后分享一点我踩过坑后的个人体会我见过有人一上来就啃官方文档和底层原理结果啃了俩月还在纠结“Git 对象模型是什么”代码一步没推。也见过有人压根不看原理直接靠鼠标点按钮结果遇到一次删除冲突就整个仓库翻车。最理想的路径其实就是这条先跑通第 2 节到第 6 节的核心闭环建立起“工作区、暂存区、版本库、分支、远程”这几个最基本的心智模型然后在日常使用中遇到一个坑就加深一层理解等到你把merge和rebase的区别弄明白时你已经比相当一部分开发者强了。如果再让我带一个零基础的新人我会让他先把git reset --soft和git restore --staged这两个命令背下来。因为一个管提交后悔一个管暂存后悔平时真的天天用到。另外想提醒你的是不要有事没事就想着重写历史。虽然git rebase -i看着很牛但对协作中的分支大规模改写提交历史往往是灾难现场。我自己的习惯是只有在我确定这个分支只有我一个人在用时才会用rebase整理提交。否则一律用merge简单、诚实、不出幺蛾子。操作之前心里默念三遍先看状态先看状态先看状态。几乎所有事故都是因为在执行命令前没有用git status确认当前头在哪里、哪些文件有变动。把这件事变成肌肉记忆你在 Git 上踩的坑会少掉一大半。看完这篇挑个目录实践一下把核心闭环跑通。那些还没讲到的高级技巧等你真正需要的时候再回来翻就好。