每年实习季工位上的第一声惨叫基本都跟需求无关而是一句“我的 git 怎么 push 不上去”。Git 这东西大学课程里可能没细讲但一进公司第一天拉代码、第二天提测、第三天被 review 打回全程都是它。很多所谓“实习干货”其实不过是一套能让你在工位上不露怯的 git 操作惯性和避坑意识。这篇文章我就按实习生从入职到日常开发的真实路径把 git 安装、配置、提交、分支、合并、远程仓库、常见报错一次捋完顺便补上那些文档里不写、但你在终端里一定遇得上的细节。1. 先搞清楚Git 到底在替你解决什么问题1.1 它不是网盘是一台带后悔药的代码时间机器以前用 SVN 的同学可能更熟悉“中心仓库再加本地工作副本”的模式所有版本备份都集中在服务器。而 Git 是分布式的你本地 clone 下来的不只是当前一份代码而是整个仓库的完整历史包括所有分支、所有提交记录。这意味着断网也能提交、也能看历史、也能回滚只是暂存到本地等到联网再推送到远端。这个“本地也有完整历史”的设计是理解 Git 一切行为的底层前提。你在本地每 commit 一次Git 就会记录当时整个项目树的一个快照并指向它的父提交。每个提交有一个哈希值。这个哈希一旦生成就基本不可变变的就是分支指针。所以“回滚”本质上是把分支指针拨回历史某个节点而不是真的删除什么。这也是为什么很多人觉得 git 折腾坏了好几天其实是分支指针乱了对象都还在。明白这一点后面所有高级操作你都不会慌。1.2 Git 和 SVN 的核心差异一张表说清对比项SVNGit仓库位置集中式必须联网访问中央服务器分布式本地克隆完整历史提交方式直接提交到中央仓库先提交到本地再 push 到远程分支体验分支廉价但合并痛苦分支极廉价合并和拆解都很灵活离线工作较难完全支持新手常见误区改完就提交觉得安全提交是自己仓库的事push 才是给别人看我见过太多刚转 git 的同学把 git 当成 SVN 客户端用改了文件就 commit然后立刻 push还总担心提交太快泄露半成品。其实正确姿势是小步提交、频繁提交把历史留给自己把诚意留给 push。提交是给自己看的push 是给别人看的这两个动作的职责完全不一样。2. 安装和初始化配置别卡在第一公里2.1 Windows 安装 Git 的两种常见姿势直接抄作业Windows 上装 Git我推荐直接去 git-scm.com 下载官方安装包版本号见官网为准。安装过程有几个选项很多人直接下一步后面踩坑才知道全是从这里埋的“Adjusting your PATH environment”选 “Git from the command line and also from 3rd-party software”这样在 cmd 和 PowerShell 里都能直接敲 git 命令。“Choosing HTTPS transport backend”保持默认 “Use the native Windows Secure Channel library” 即可公司代理环境下也少点证书问题。“Configuring the line ending conversions”选 “Checkout Windows-style, commit Unix-style line endings”。这是最不坑的选项后面换行符的幺蛾子基本都靠它防着。终端模拟器选 “Use MinTTY” 就好操作体验更顺复制粘贴不打架。如果你更习惯用包管理器也可以在 PowerShell 执行winget install --id Git.Git -e --source winget同样能装好。装完一定要开一个新终端敲git --version验证一下。如果提示找不到命令八成是 PATH 没生效重启终端或重新登录一次系统就能解决。macOS 上最简单的是先跑xcode-select --install装命令行工具里面自带 git需要新版本可以brew install git。Ubuntu 上则是sudo apt update sudo apt install git装完同样验证版本。2.2 下载慢或者官网打不开换镜像源git 官方安装包放在 GitHub Releases 上国内下载经常慢到怀疑人生。这时候不要硬等直接换清华 TUNA 镜像站https://mirrors.tuna.tsinghua.edu.cn/github-release/git-for-windows/git/进去选对应的版本号和Git-版本-64-bit.exe文件即可。阿里云也有类似镜像不定大家自己搜公司内网有没有缓存。装完 git 之后如果你浏览器访问 GitHub、Gitee 等代码托管平台慢那属于网络问题和 Git 本身无关。解决办法是优先使用国内托管平台或者公司自建的 GitLab日常工作体验会好非常多。这也是实习生入职后第一件事尽快确认的公司代码库是放在哪套平台的。2.3 装完立刻要做的事身份、换行符、默认分支名所有提交记录都会带着提交者姓名和邮箱所以在第一次 commit 之前必须配置git config --global user.name 你的名字 git config --global user.email 你的公司邮箱这里有个很多人不理解的细节为什么邮箱要用公司邮箱因为很多代码评审系统会按邮箱关联到你的企业账号。如果随便填一个个人邮箱提交记录就只能显示一个幽灵用户后续统计工作量、机器人通知都会对不上人。所以入职第一天先把这两条配好。再顺手把换行符策略和默认分支名定下来git config --global core.autocrlf true # Windows 上推荐 git config --global init.defaultBranch main # 新仓库默认 main 分支core.autocrlf true的意思是checkout 时把 LF 转成 CRLFcommit 时再转回 LF。这能避免团队里 Windows 和 macOS/Linux 互相改文件导致整文件 diff 的惨剧。如果不设这个你很可能某天打开文件发现所有行都被标记为改动代码评审直接爆炸。最后建议配几条好用别名能在日常操作节省大量时间git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.cm commit -m git config --global alias.lg log --oneline --graph --all --decorategit lg是我最常用的一个歪歪扭扭的提交线一眼看明白当前处于哪个节点。新手必须会看这个图否则分支合并很容易在脑海里变成一团浆糊。3. 日常提交三连从懵懂到肌肉记忆3.1 理解工作区、暂存区、本地仓库三个抽屉Git 把一个项目分成三个区域很多人始终没搞明白为什么 commit 之前非要先 add 一下。我用一个生活化类比解释工作区是你的工位代码改完了像草稿纸堆在桌上git add是把要打包的草稿挑出来放进公文包这个公文包就是暂存区git commit是正式把公文包里的草稿装订存档存入本地仓库。你完全可以在桌上放一堆草稿只挑一两张放进公文包提交所以 add 的意义是“选择本次提交要包含哪些改动”。日常最频繁的操作就是三连git status # 看工作区、暂存区状态 git add 文件路径 # 把改动加入暂存区也可以 git add . 加全部 git commit -m 提交说明每次想提交前先跑git status不要盲打。它能很清楚地告诉你哪个文件改了还没 add、哪个文件 add 了还没 commit、哪个文件是未被跟踪的新文件。养成这个习惯后你会发现误提交的概率跳水式下降。git add .是新手最爱但也是最危险的操作因为会把所有改动、删除、未跟踪文件一锅端。如果临时目录或者敏感文件没写进.gitignore很容易被顺带上车。我个人的规范是新项目先写好.gitignore因为里面至少要知道忽略node_modules/、target/、bin/、*.log、.idea/、.vscode/这类目录。可以现成的模板从 GitHub 的 gitignore 仓库拿也可以让人帮你生成但核心是不要忽略代码里需要的配置文件。3.2 提交信息怎么写才算不丢职场人commit message 是团队协作的说明书。常见的规范是 Angular 团队推广的约定式提交格式大致为type(scope): subject常见 typefeat新功能、fix修复、docs文档、refactor重构、chore构建或辅助工具变动、style格式调整。例如feat(user): 新增用户头像上传接口 fix(order): 修复订单状态重复更新的问题 docs(readme): 补充本地开发环境启动步骤如果公司没有强制的 message 规范你也至少要把“做了什么”写清楚而不是写update、fix bug、111。要知道同事 review 代码时第一眼看到的就是提交信息它能帮你省掉大量“这个提交改了什么”的在线提问。同时提交尽量保持单一职责一个提交只解决一个问题。这样后续用git bisect二分定位问题、用git revert回滚单个功能时会从容得多。3.3git commit --amend到底怎么用为什么不建议乱用git commit --amend的作用是修改最近一次提交而不是新追加一个提交。它的常见使用场景有两个场景一上次提交信息写错了git commit --amend -m 正确的提交信息场景二上次提交漏了一个文件想并进去git add 漏掉的文件 git commit --amend --no-edit # 保留原提交信息把文件加入上一次提交这里的问题在于amend不是原地修改而是会生成一个新的提交哈希相当于把原来的提交“覆盖”掉了。所以它只适用于还没有 push 到远程的提交。如果已经 push 了再用 amend 改写历史下次 pull 时远程和本地历史对不上会得到意外的 merge 或报错。团队里同事如果已经拉过你的那笔提交历史改写会造成很大的困扰。真实场景里实习生最容易遇到的状况是提交到远程后发现信息写错了。正确做法是分情况处理。如果是刚提交还没人协作可以 amend 后强推git push --force-with-lease如果提交已经过去很久、或者已经被别人基于它开发就不要再改历史了宁可重新提交一个修复提交也不要为了“整洁历史”把队友搞崩溃。3.4git log和git diff随时能看过去和现在git log负责看提交历史常用参数就这几个git log --oneline # 一行一个提交 git log --oneline --graph # 带分支拓扑图 git log --oneline -5 # 只看最近 5 条git diff负责看改动内容这个更是天天用。默认git diff比较的是工作区与暂存区的差异也就是你自己改了还没 add 的东西git diff --cached比较暂存区与上一次提交的差异也就是你准备提交的改动。提交前先跑一次git diff --cached等于在发车之前检查一遍行李有没有装错这个习惯能挡掉 90% 的“提交了不该提交的文件”事故。4. 分支与合并团队协作的命根子4.1 分支就是一个平行时空随便开分支为什么重要它让你可以在同一份代码上同时开发多个功能而互不干扰。常用命令git branch # 列出本地分支 git branch 分支名 # 创建分支 git checkout 分支名 # 切换分支 git checkout -b 分支名 # 创建并切换分支 git branch -d 分支名 # 删除已合并的分支新功能我一般都会用feat/xxx的命名方式比如feat/login-page修复用fix/xxx或hotfix/xxx。团队如果已经有分支规范直接跟规范别自己发明。这里有个源头容易懵的点新建分支并不是复制一份代码文件它只是创建一个指向某个提交的指针。所以你切分支很快同一个工作目录里切换分支后文件内容会对应切换过去。这就带来一个配合操作如果你在一个分支里改了文件还没提交切到另一个分支时那些改动会跟着“带过去”。因此切换分支前先git status确认工作区是否干净。要么提交、要么暂存、要么 stash否则极容易把半成品带到别的分支。git stash也是一个实习高频命令手上改到一半突然要修线上 bug可以先git stash push -m 半成品保存现场切到修复分支处理完再切回来git stash pop。注意 pop 可能产生冲突不过冲突也只是回到你当初改文件的上下文解决起来并不困难。4.2 三种合并姿势merge 的两种形态和 rebase 的取舍分支开发完要并入主干最常见的命令是git checkout main git pull git merge 功能分支这里会出现 fast-forward 合并和 merge commit 两种结果。简单说如果要合并的目标分支没有新的提交merge 会直接把分支指针往前挪历史是一条直线这叫 fast-forward如果主干在你分出去之后已经有新提交merge 会创建一个新的合并提交历史呈现分叉再交汇的形状。团队到底用 merge 还是 rebase是千古难题。我给的实习生建议是先掌握 merge 保平安再慢慢理解 rebase。git rebase的作用是把当前分支的提交“摘下来”重新接到目标分支的最新提交之后听起来很干净但它是改写历史的行为自己本地怎么玩都行push 出去之后再 rebase 就会给团队带来同步灾难。按我个人的工作习惯本地 feature 分支开发期间如果主干更新了我会用 rebase 把功能补丁平移到最新主干上这样合并时历史干净得多一旦 push 到远程、别人开始拉取了这个分支之后就坚决只用 merge 了。4.3 冲突的解决套路我给你一步步摊开合并时最怕的是冲突但它其实并不可怕。冲突发生在两个分支修改了同一个文件的同一部分Git 不知道你到底想保留哪一边只能把决定权交给你。当你执行 merge 后看到CONFLICT (content): Merge conflict in src/main/java/com/example/UserService.java此时打开冲突文件会看到如下标记 HEAD 当前分支的代码 合并进来的分支的代码 feat/user-info解决方式就是编辑这个文件把三行标记和不需要的代码清理掉只留下最终想要的版本。手动处理完后对相关文件执行git add 冲突文件 git commit # 或者继续完成 merge 的提交如果冲突文件非常多强烈建议别在终端裸手改用 VSCode 或 IDE 的冲突解决工具。VSCode 里打开冲突文件会看到 “Accept Current Change / Accept Incoming Change / Accept Both Changes / Compare Changes” 等按钮直观很多。解决完所有冲突后跑一下git status确认没有剩余 unmerged 文件再 commit才算真正收工。当然冲突多少和代码组织强相关。减小冲突最朴素的手段就是小步提交、频繁同步主干、不要一个分支做一个月。分支活了越久和主干分叉越厉害冲突概率指数上升。这是代码管理的经验问题不是 git 命令的问题。5. 远程仓库联动clone、push、pull 和 SSH5.1 配一次 SSH 密钥以后再也不用输密码公司里通常用 GitLab、Gitee 或者 GitHub 托管仓库。最省心的认证方式是 SSH。配好之后 push 和 pull 都不需要每回输账号密码体验好上不止一个档次。生成密钥ssh-keygen -t ed25519 -C 你的邮箱 -f ~/.ssh/id_ed25519一路回车即可如果担心安全问题也可以设置 passphrase。生成的公钥对应文件是~/.ssh/id_ed25519.pub把这个文件内容复制出来。然后到代码托管平台的设置页找到 SSH Keys 或 SSH 公钥管理入口把公钥内容粘进去保存。测试连接ssh -T gitgitee.com # Gitee ssh -T gitgithub.com # GitHub看到欢迎语或successfully authenticated字样说明通了。之后克隆仓库、push 都走 SSH 地址比如git clone gitgitee.com:username/project.git这里有个关键点要反复念叨~/.ssh/id_ed25519是私钥绝不能泄露更不能提交到仓库里。公钥随便传私钥满大街就没救了。如果你工作机和家里的电脑都要用分别生成各自的密钥再分别添加到平台不要拷来拷去。5.2 clone、push、pull 的完整流程与方向感第一次接触项目时一般是git clone 仓库地址 cd 项目目录 git checkout -b feat/my-task # 拉出自己的功能分支开始开发后循环往复的节奏是git status git add 文件 git commit -m feat: 完成某功能 git push -u origin feat/my-task之后想同步同事新提交的内容git pullgit pull的本质是 fetch 加 merge。fetch 把远程更新拉到本地但不动你的工作区merge 再把远程分支并入当前分支。如果你本地没有未提交的改动pull 基本是无感的如果本地有改动且和远端改动同一个文件就会出现 merge 冲突。第一次 push 新建分支时用-u参数作用是建立当前本地分支和远程分支的跟踪关系。之后直接git pushGit 就知道推到哪里去。如果推送失败最常见的提示是远程分支有更新需要先git pull再推。这是好事Git 在阻止你用旧状态覆盖别人新写的代码。5.3 SSH 认证失败按照这个顺序排查SSH 认证失败的报错长什么样一般有Permission denied (publickey)或者更笼统的gitgithub.com: Permission denied (publickey)。这时候别慌按顺序检查第一确认你用的是 SSH 地址而不是 HTTPS 地址。HTTPS 地址长这样https://github.com/user/repo.gitSSH 地址是gitgithub.com:user/repo.git。地址错了认证走的路就完全不对。第二ssh-agent有没有加载你的私钥eval $(ssh-agent -s) ssh-add ~/.ssh/id_ed25519Windows 上如果你用 Git Bash这套也适用。装 Git 时的 OpenSSH 自带 ssh-agent但是服务可能没启动可以手动启动后加入启动项。第三本地公钥和平台上的公钥是否一致。重新复制一次本地公钥内容到平台对比如果换了电脑却忘了换公钥就很容易出现权限拒绝。第四一些企业内网环境会封 22 端口SSH 连不上。GitHub 和 GitLab 通常提供 443 端口的 SSH 配置可以在~/.ssh/config里写Host github.com HostName ssh.github.com Port 443 User git如果你的网络环境确实有这种限制用这个配置能救急。如果还不行退而求其次改用 HTTPS 地址推送时使用账号和访问令牌或密码也能正常干活。5.4 切换远程仓库、清除本地的账号密码残留离职交接或者账号变更时本地可能会记住一堆旧凭据。Windows 上最常见的是凭据管理器里存了旧 git 账号push 时一直不弹窗、怎么都切不过去。查看当前凭据助手git config --global credential.helperWindows 通常会返回manager或manager-core。这会调用 Windows 凭据管理器。清除指定主机凭据可以使用cmdkey /list | findstr /i git cmdkey /delete:git:https://gitee.com执行时确认主机名别写错就行。VSCode 里也可以用账户面板清除缓存或者重启后重新登录。如果只是临时想用另一个账号推还可以对单个仓库配置不同的用户名邮箱git config user.name newname git config user.email newemail注意不加--global就是局部覆盖。不要动不动就在本地全局改身份否则提交记录会张冠李戴。6. 实习生最容易踩的坑急救清单收好6.1fatal: not a git repository到底是谁的锅这个报错我几乎每周都能在同事群里看到完整提示一般是fatal: not a git repository (or any of the parent directories): .git原因很简单你在一个不是 git 仓库的目录里执行了 git 命令。可能是你cd到了项目外层目录可能是 clone 之后没进到目录里也可能你把.git文件夹不小心删了。解决办法也不复杂先pwd看看自己在哪。再ls -a看看当前目录有没有.git。如果确实在项目根目录却提示这个错检查是不是误删了.git。如果是重跑git clone即可别尝试从零git init去救除非你完全懂 init 和 clone 后的差异。有个小技巧可以避免频繁进出目录任何地方都能查看指定仓库状态git -C /path/to/project status6.2 代码丢了先去看看git reflog我见过很多次“我把这个分支删了代码还有吗”的求救。Git 不会轻易丢核桃删分支本质只是删了分支引用而提交对象一般还留在对象库里。普通git log看不到被删除分支上的提交但git reflog能看到所有分支指针曾经移动过的记录。执行git reflog输出类似a1b2c3d HEAD{0}: checkout: moving from feat/xxx to main e5f6g7h HEAD{1}: commit: feat: 完成登录页面找到你要恢复的提交 sha然后git checkout -b recover e5f6g7h一条新分支就带着那笔提交重新出现了。如果是误reset --hard丢的本地改动同样可以用 reflog 找到 reset 之前的提交。记住先入为主遇到 git “丢东西”第一反应不是重写代码而是 reflog 查命案。6.3.git目录和敏感文件不能出现在不该出现的地方.git目录里存着整个仓库的历史、远程地址、甚至原来的配置信息。有些新手会把整个项目压缩包发出去压缩前忘了过滤.git或者把项目直接传到另一个公开仓库等于把内部历史和潜在敏感信息打包送人。发到企业内部群还好如果发到外部风险就很麻烦。另外常见的是把.env、私钥、config.php这类带密码的配置文件提交进仓库。等到发现时历史里已经有脏数据了单纯删除文件再提交并不能把历史清理干净因为历史提交里还留着。正规处理方式是使用git filter-repo或者git filter-branch重写历史不过这类操作复杂度高、风险也不小最好找有经验的老同事一起搞。所以最好的策略是预防项目一初始化就把.gitignore写好提交前git status扫一眼push 前用git diff --cached再确认一回。6.4 IDE 和 Git 联动的几个顺手配置刚入职的实习生很多直接用 VSCode 或 JetBrains 系 IDE。这里也整理几个常用配置。VSCode 里如果装了 Git 扩展可以在设置里指定 git 路径git.path指向 Git 安装目录下的cmd/git.exe。代码栏里点开源代码管理可以看到所有改动提交时可以勾选文件比命令行直观。VSCode 里首次提交前如果没有配置姓名邮箱会提示你扫码登录或是输入实际上它底层还是调 git config。IDEA 里创建新项目并拉取 Git 仓库步骤是New Project → 选择 Git → 粘贴仓库地址 → 选择目录 → 完成。IDEA 的 Git 窗口也提供了分支切换、合并、日志图谱、提交等图形化操作。我强烈建议新手先在 IDE 或图形工具里把“分支”“合并”“冲突解决”这几个操作形成直观印象再回到命令行理解会深很多。命令行也别死磕 Windows 自带的 cmd建议日常用 Git Bash。Git Bash 的体验在路径转换、命令补全、快捷键方面都舒适得多。如果你在 PowerShell 里用 git注意某些符号转义问题遇到奇怪现象先换 Git Bash 试试。6.5git worktree一个仓库同时展开多个分支最后分享一个提升到进阶但非常好用的命令git worktree。默认情况下一个本地仓库在同一时刻只能 checkout 一个分支。有时候你正在分支 A 改代码同事让你切到分支 B 帮忙查个问题你又不想 stash 改动传统做法很纠结。git worktree允许你从同一个仓库关联出多个工作目录git worktree add ../project-feat feat/urgent-fix cd ../project-feat # 这里就是一个干净的分支 B 工作区操作完不需要这个目录时git worktree remove ../project-feat如果删除时提示有未合并信息可以先git worktree prune清理旧索引。这个命令特别适合多任务并行时省去来回 stash 的提心吊胆。不过对纯新手来说可以先不展开了解等业务复杂到必须同时开多个分支时再回来学。说到底Git 并不难难的是你把它当成一次只能跑对的程序。其实 git 的设计给了你很多后悔的机会local 分支随便删都能抢救push 之前的一切操作几乎都可逆。真正要小心的只有两件事一是 push 到共享分支之后不要轻易改写历史二是不要把敏感信息提交进去。前者靠约定和纪律后者靠.gitignore和提交习惯。我这些年带过的实习生第一周基本都在和 git 搏斗。但坦白说只要把status、add、commit、push、pull、merge这六个命令形成肌肉记忆再配合今天梳理的报错排查路径你已经在绝大多数日常场景里畅通无阻了。最后再分享一个个人习惯每到一个新环境我都会先跑一遍git config --list --show-origin看看当前所有配置是从哪来的。这一条命令能让你在任何陌生电脑上迅速搞清 git 的当前状态省掉大量“为什么它不按我的想法工作”的疑惑。希望这篇能把你在第一份实习里的 git 焦虑减掉一半剩下的就交给多练了。