做开发这些年我见过太多人栽在同一个地方代码明明写好了想把文件传到 GitHub 的指定目录结果要么传到仓库根目录要么把临时文件一股脑推了上去做分支合并时又在 merge 和 rebase 之间反复横跳冲突一多直接原地蒙圈。其实把这些场景拆开看它就是一套固定动作本地把文件组织好用 git add 和 git commit 打上快照再按分支规则把提交推到 GitHub 对应路径最后把分支合并回目标分支。这篇文章就是来把这条完整链路讲透的覆盖 Git 安装配置、上传到指定文件夹、分支合并、冲突解决以及我真实遇到过的报错和排查过程。适合刚接触 Git 的开发者也适合已经会用基础命令、但对分支始终没把握的人。1. 把“上传文件”和“分支合并”看成一个连续动作1.1 指定文件夹在 Git 里到底是什么“上传文件到 GitHub 的指定文件夹”这句话特别容易让人产生网盘的联想以为选中一个文件扔到某个远程目录就完事了。实际在 Git 工作流里根本没有“远程文件夹”这个独立概念只有“仓库根目录下的相对路径”。GitHub 仓库从根目录开始就是一棵文件夹树你在网页上看到的 docs/notes/readme.md本质上是本地仓库里 docs/notes/ 这个相对路径下的一份文件在 push 之后被远程展示了出来。所以“上传到指定文件夹”的真正含义是确保本地路径正确让文件进入暂存区提交到本地版本库再推送远程分支。远程目录结构不会凭空出现它完全取决于你本地仓库的目录结构。很多人会在这一步犯一个基础错误以为只要用 Git 命令指定一个远程路径就能把一个本地文件直接放进任意目录。其实 Git 从未提供这种“魔法”命令。正确做法永远是把文件先放到本地仓库对应目录再 add、commit、push。理解了这一层后面就不会再纠结“为什么我 push 之后文件不在想放的文件夹里”了。1.2 为什么推荐用 Git 命令而不是网页端拖拽网页端其实支持直接上传文件甚至支持拖拽。但这种方式有两个明显问题一是不适合批量操作几十个文件还要逐个定位目录二是没有经过本地校验缺少 diff 检查和 commit 记录控制很容易把不该传的东西传上去。更重要的是网页上传无法解决“分支合并”这个后续动作。你写代码总不可能永远是直线发展今天在 main 上改一点明天在 feature 分支上改一点最终都要走向合并。合并发生在 Git 的对象体系里而不是文件夹层面。用本地命令流每一笔变更都有据可查合并时也能清楚看到两个分支各自做了什么修改。我个人的习惯是把网页端上传当成应急通道比如临时补一份说明文档、改一下 README 错别字凡是涉及正经开发内容的文件一律通过本地 Git 流程走。这样既保证历史记录完整也方便在合并之前做 review。1.3 一条完整工作流包含哪些动作可以把“上传文件”和“分支合并”放进同一个流水线里看待。举例来说你在 feature/docs 分支上修改了 docs/guide.md先 add、commit把这个提交推到远程的 feature/docs 分支然后切回 main把 feature/docs 合并进来最后 push main。这一步里push 和 merge 是配合出现的push 负责把本地提交同步到远端merge 负责把不同分支的历史整合成一条完整主线。很多新手的混乱点在于分不清“推送到某个分支”和“合并到某个分支”的区别。假设你本地在 feature/log 分支直接执行 git push origin main如果 main 没有新的远程提交Git 会尝试用当前 feature/log 的历史去快进更新 main如果两边分叉就可能被拒绝或者需要强力覆盖——无论哪种都不会产生“像 merge 那样干净的合并记录”。所以更安全的方式是先推自己的分支再通过 merge 或 rebase 把改动合进目标分支最后推目标分支。先文件后合并合并完再推送这条顺序应该成为肌肉记忆。2. 环境准备装好 Git、配好身份、连通远程仓库2.1 Windows 下安装 Git 的完整流程与坑点如果你在 Windows 上开发直接搜索“git for windows”下载安装包后一路 Next 就可以。但有两个选项值得留意一是安装完成后建议把“Git Bash Here”和“Git GUI Here”的右键菜单打开后面在任意目录里打开 Git Bash 会非常方便二是默认编辑器如果没设过可以保留 Vim也可以用 VS Code看个人使用习惯我在第一次配置时就把默认编辑器设成了 VS Code避免后来 commit 时误入 Vim 出不来的尴尬。安装完不要忘记验证。打开终端或者 Git Bash执行 git --version能看到类似 git version 2.23.0.windows.1 这样的输出就说明安装成功。这里有个小坑如果是刚装完之前的终端窗口可能还没加载新环境变量要重新打开一个终端窗口再执行。我遇到过好几次“明明装好了却提示不是内部或外部命令”就是没重开终端。还有个容易被忽略的问题安装时如果选择了“调整 PATH 环境变量”选项Git 会把它的 bin 目录写进系统 PATH。旧版本偶尔会出现和已有的开发工具链冲突的情况所以安装完成后顺手执行 where git 看一下当前到底用的是哪个 git能少踩很多环境坑。2.2 第一次使用必须配置的两项身份信息Git 提交记录里会记录“谁改的”靠的就是 user.name 和 user.email。不配置的话Git 可能会用系统默认用户名提交记录看起来就是一串莫名其妙的机器名协作时根本对不上人。配置方法很简单git config --global user.name 你的名字 git config --global user.email 你的邮箱这里的邮箱建议直接用 GitHub 账号里绑定过的邮箱这样提交记录的头像和账号信息才能关联上。如果想对某个仓库单独配置把 --global 去掉在该仓库目录下执行即可。除了身份信息还有两个建议顺手做掉git config --global init.defaultBranch main git config --global pull.rebase false第一行让新仓库默认分支叫 main避免本地建仓库时默认 master、远程又是 main两边对不上第二行让 pull 默认使用 merge 策略比较符合多数开发者的直觉。至于为什么这么说后面讲合并策略时会细讲。2.3 SSH 密钥和 HTTPS 凭证二选一怎么选连 GitHub 有两种主流方式HTTPS 和 SSH。HTTPS 对新手更友好clone 地址形如 https://github.com/user/repo.gitpush 时输入用户名和访问令牌Token即可。现在 GitHub 已经不支持用账号密码直接 push必须用 Personal Access Token这一点很多人还不清楚老报“Password authentication has been disabled”。SSH 方式更省心只需要把本地生成的公钥放到 GitHub 账号里。生成密钥ssh-keygen -t ed25519 -C 你的邮箱一路回车之后默认会在用户目录下生成 id_ed25519 和 id_ed25519.pub 两个文件。用编辑器打开 .pub 文件复制全部内容到 GitHub 的 Settings - SSH and GPG keys 里新增即可。验证是否连得上ssh -T gitgithub.com看到 “Hi username! Youve successfully authenticated” 就说明 SSH 打通了。我个人更推荐 SSH尤其是需要长期维护的项目一次性配置好后就不再需要反复输入 Token。不管用哪种方式都要记得检查远程地址本身git remote -v如果显示的是 https:// 开头说明走了 HTTPS如果显示 gitgithub.com:user/repo.git说明走了 SSH。远程地址不对后面所有 push 都会跟着错。3. 实操步骤把文件放进 GitHub 的指定文件夹并推上去3.1 场景一已有远程仓库本地从空目录开始这是最常见的场景GitHub 上已经有一个仓库你想在 docs/notes/ 这个目录下新增一份笔记文件本地还没有这个仓库的副本。推荐先克隆整个仓库而不是在本地 init 一个不相关的目录。git clone gitgithub.com:user/repo.git cd repo mkdir -p docs/notes cp ~/Desktop/note.md docs/notes/ git status git add docs/notes/note.md git commit -m docs: add note git push origin main一步步看clone 会把远程仓库完整拉到当前目录相当于把远程目录树整体复制到本地。mkdir -p 是确保路径存在-p 的意思是“没有就创建有就不报错”。cp 是把文件放进去这一步决定了你实际要上传的“指定文件夹”。git status 是为了看变更清单。此时 note.md 会以 Untracked 状态出现add 指定路径后它就进入暂存区。commit 是打个本地快照push 则是把这个快照同步到远程的 main 分支。这里有个很多人容易忽略的点如果你在仓库里新建了一个空文件夹Git 并不会跟踪它GitHub 上也看不到这个空目录。因为 Git 跟踪的是文件不是文件夹。非要保留空目录就在里面放一个内容为空的 .gitkeep 文件这是一种通用惯例很多开源项目都在用。3.2 场景二本地项目是全新的要整体建档上线另一种场景是本地已经写好了一个项目GitHub 上还没有仓库或者只有一个空仓库。此时不需要先 clone 再重新摆放文件直接在项目根目录初始化git init git branch -M main git add . git commit -m init project git remote add origin gitgithub.com:user/repo.git git push -u origin maingit init 会在当前目录生成 .git让这里成为 Git 仓库。git branch -M main 是把分支名强制改成 main和 GitHub 默认分支保持一致。git add . 是把当前目录所有未忽略文件加入暂存区这一步风险最大很容易把临时文件、编译产物、密钥文件一股脑加进去所以 .gitignore 必须提前写好。git remote add origin 是把本地仓库和远程仓库关联起来。最后 push 时的 -u 参数很关键它会建立本地 main 分支和远程 main 分支的跟踪关系后续直接执行 git pull 或 git push就不用再写完整参数了。如果你只想要指定文件夹不想把整个项目根目录都推上去那就在 git add 时给具体路径例如 git add docs/或者用 git add docs/guide.md。Git 允许只提交部分内容这在只需要更新某个子目录的场景下非常管用。3.3 场景三单文件小改动用网页端应急如果只是简单补一个文件比如 README 里的一张样例图或者一个配置文件直接用 GitHub 网页端的 Add file 按钮也能实现“上传到指定文件夹”先进入对应目录再点 Add file - Upload files或者创建新文件时路径栏里直接写文件夹名/文件名GitHub 会自动按路径创建目录。这种方式胜在快不用走完整本地流程。缺点也很明显批量文件不方便历史记录只有一条 web commit很多规范公司不允许直接用网页改代码。我的建议是网页端只用来处理文档、素材、配置文件真正的源码、需要检测的脚本走本地 Git 流程。三种场景对比如下方便按情况选场景推荐方式原因已有仓库新增指定目录文件本地 clone 后 git add保留完整历史可本地校验本地新项目上线本地 init 后关联远程目录结构原样映射批量处理可控单文件小改动网页端极速处理免安装、免克隆文档类可接受3.4 大文件和敏感文件怎么处理GitHub 对单个文件有 100MB 的硬限制建议超过 50MB 的文件就不要直接塞进仓库了。大文件要用 Git LFSLarge File Storage它把大文件本体放到单独存储仓库里只保留一个指针文件需要时再拉取真实内容。安装 LFS 后先执行 git lfs install然后对指定格式做跟踪git lfs track *.zip git add .gitattributes git commit -m chore: track zip files with lfs至于敏感文件比大文件更危险。比如 .env、密钥、数据库导出文件一旦进过 Git 历史即使后来删除也会残留在历史提交里。最好的处理方式是压根不让它进仓库在 .gitignore 里写清楚.env *.pem node_modules/ dist/一个实用技巧执行 git add . 之前先看一眼 git status 的输出确认被追踪的文件列表里没有不该出现的文件。养成这个习惯能避免九成以上的“误传密钥”事故。4. 分支合并从创建分支到落地合并完整走一遍4.1 分支不是复制文件而是移动指针Git 里的分支本质上是一个可移动的提交指针。创建分支不是复制代码而是给当前提交打一个新的标签未来在这个分支上提交时指针会跟着新提交前进。理解这一点就能明白“合并分支”其实是在整合提交历史而不是比较两个文件夹谁新谁旧。创建和切换分支的标准命令git switch -c feature/add-log这条命令等于 git branch feature/add-log 加 git switch feature/add-log一步到位。更早版本的 Git 用 git checkout -b 也能达到同样效果两种写法我都用过现在更推荐 switch语义更清晰不容易误操作。如果你是要基于远程分支开发比如远程有个 feature/one 分支想拉到本地接着改git switch -c feature/one origin/feature/one这样本地分支就自动关联了远程的 feature/one后续 push 时可以少打参数。4.2 用 merge 完成分支合并三种结果一次讲清merge 就是把另一个分支的历史整合进当前分支。具体会出现三种结果取决于两个分支是否有分叉第一种是 fast-forward 快进合并。当前分支没有任何新提交另一个分支领先了一段提交此时 Git 只需要直接把当前分支指针往前移动不会产生额外的合并提交历史是一条直线。举例main 的提交是 A从 A 拉出 feature 分支后提交了 B 和 C此时 main 还停在 A那么切回 main 执行 git merge feature结果就是把 main 从 A 直接移动到 C速度最快且没有合并痕迹。第二种是 --no-ff 合并也就是强制生成一个合并提交。即便可以 fast-forward仍然想让历史记录明确标注“从这里合并了 feature 分支”就可以用git switch main git merge --no-ff feature/add-log这样会生成一个新的 merge commit提交信息默认是 Merge branch feature/add-log。很多技术团队喜欢这种模式因为可以从提交图上清楚看到每次合并的边界方便回溯紧急改动。第三种是真正的三方合并。两个分支都有各自的新提交历史出现分叉Git 会对比两个分支从共同祖先以来的所有改动然后生成一个合并提交。如果两边改的不是同一个文件或者改的是同一个文件的不同位置Git 能自动合并成功如果改了同一个文件的同一处就会产生冲突需要手动处理。一个常见困惑是“为什么我 merge 之后没有生成 Merge commit”。原因很简单Git 判断可以 fast-forward就没必要多此一举。想要强制看到合并提交就加 --no-ff。用表格总结合并结果触发条件是否产生 merge commit提交历史fast-forward目标分支没有新提交否直线型--no-ff主动要求保留合并节点是出现分支节点三方合并两个分支都有分叉提交是有明显分叉汇聚4.3 rebase 合并是不是更好的方式除了 merge还有一种整合分支的常见方式叫 rebase。它的思路是把当前分支的提交重新“嫁接”到目标分支的最新提交之后让提交历史变成一条直线。git switch feature/add-log git rebase main执行完以后feature 分支的提交会被重新应用到 main 的最新提交之后。如果你的代码有冲突会在每个提交重放时依次处理而不是像 merge 那样最后统一处理一次。rebase 的好处是历史干净不会出现一堆 Merge branch 节点坏处是它会改写提交顺序和哈希值一旦分支已经被推送到远程再 rebase 就需要强推而强推会覆盖别人的提交协作场景下非常危险。所以我的经验是对于还没推送到远程的本地分支可以放心用 rebase 整理提交对于已经和同事共享的分支用 merge 更安全。判断标准就一句话——这段历史有没有被别人拉走过有就 merge没有才 rebase。在实际项目里我常用的组合拳是在 feature 分支开发提交若干次推送到远程创建 Pull Request等 review 通过后直接在远端 Merge。本地不反复 rebase避免给协作者制造信息差。4.4 冲突解决不要怕按这个顺序处理冲突是合并中最让人紧张的环节但它的本质只是 Git 不知道怎么替你决定保留哪一版。这时 Git 会在冲突文件里插入冲突标记 HEAD 这里是当前分支的代码 这里是另一个分支的代码 feature/add-log处理步骤很简单。第一步先看 git status找到标记为 both modified 或 unmerged 的文件第二步用编辑器打开文件逐个确认冲突段保留正确内容删掉冲突标记第三步把处理完的文件重新加入暂存区第四步直接 commit 完成合并。git status # 编辑冲突文件 git add docs/guide.md git commit -m merge: resolve conflict in docs/guide.md如果中途发现操作错了或者合并进来一堆自己看不懂的改动可以随时退回合并前状态git merge --abort这个命令非常救命。有一次我接手一个老项目feature 分支里文件编码和主分支不一样冲突标的到处都是我第一反应就是 merge --abort然后重新梳理了分支差异再合并几分钟就搞定了。记住解决冲突前先把当前分支的干净提交保存下来再用武器的心态去面对冲突。git 的冲突标记和编辑器提示都能帮你定位真正有疑问的地方往往也就那么几个小区域。一个小建议不要试图在合并中间临时改功能。合并只负责把两份改动整合到一起如果冲突文件里出现了逻辑层面的大改动需求应该先解决当前冲突、完成合并再开新分支处理功能否则会把合并历史变得一团糟。4.5 在 IntelliJ IDEA 里合并分支怎么点很多不熟悉命令行的同学习惯在 IntelliJ IDEA 里操作 Git。IDEA 的图形化功能其实已经封装得很好而且大厂团队很多都用它。合并分支的路径是右下角或者顶部 VCS 菜单里找到 Git - Branches弹出所有本地和远程分支列表选择需要合并进来的分支点 Merge into CurrentIDEA 会自动执行 merge 逻辑。如果出现冲突IDEA 会弹出冲突对话框左侧是本地版本右侧是远端版本中间是合并结果。你可以逐行选择保留哪边也可以手动编辑中间区域。处理完后点击 ApplyIDEA 会帮你把文件标记为已解决最后 Commit 并 Push。IDEA 里也有 Abort 按钮作用等同于 git merge --abort。我个人的看法是IDEA 的合并可视化更适合新手尤其是冲突标记不直观的时候三栏对照比纯命令行友好得多。但命令行的好处是通用不管你在哪台机器、哪个 IDE只要装了 Git 就能操作不会被具体工具绑死。两条路都值得掌握。5. 高频错误实录从报错信息到处理办法5.1 fatal: not a git repository (or any of the parent directories): .git这个报错非常经典字面意思就是当前目录不是 Git 仓库或者 Git 在向父目录逐级查找时也没有找到 .git 文件夹。常见原因有两种一是你真的在某个子目录里执行了 git status而这个子目录不属于任何已初始化的仓库二是仓库根目录的 .git 文件夹被误删了或是 clone 只复制了文件内容没有把隐藏文件带上。排查方法很简单逐步向上一级目录执行 git status找到哪一层开始能识别为仓库。如果你的项目根目录确实没有 .git但文件内容都在说明当初拉取时没拉全或者这个目录从未被初始化。此时可以回到项目根目录执行 git init再关联远程地址。另一种隐蔽情况是在仓库里又执行了 git init把整个仓库嵌套进了另一个仓库。此时外层仓库会把内层目录当成一个普通的子目录或子模块提交时根本不会追踪内层仓库内部的文件很容易出现“明明 add 了但远程看不到”的诡异问题。我的处理方法是在一个项目目录里先坚定地确认谁是根仓库不要随意多重 init。5.2 SSH 认证失败 / Permission deniedpublickey执行 git push 时经常遇到类似这样的一行gitgithub.com: Permission denied (publickey).意思是 SSH 方式下GitHub 不认你当前的本机密钥。先按顺序排查一是密钥文件是否存在执行 ls ~/.ssh/id_ed25519.pub如果不存在说明密钥没生成或者路径不对二是密钥是否已添加到 GitHub浏览器登录 GitHub在 Settings - SSH keys 里查看有没有对应公钥三是本机 ssh-agent 是否加载了密钥ssh-add ~/.ssh/id_ed25519四是远端地址是不是用了 SSH。如果远端地址是 https:// 开头你推送时走的是 HTTPS 认证跟 SSH 密钥无关会报别的错误。改地址可以用git remote set-url origin gitgithub.com:user/repo.git我遇到过最迷惑的一次是VSCode 里能正常 pull但命令行 push 一直报 Permission denied。最后发现终端里当前用户和 VSCode 启动用户不一致ssh-agent 加载的密钥不是同一个。简单来说SSH 认证失败先自己按上面几步排除完全够用。5.3 git commit --amend 怎么用才安全这个命令是用来修正“最后一次提交”的。典型场景是提交完才发现漏了一个文件或者 commit message 写错了。用法是先把遗漏文件加进暂存区再执行git add 漏掉的文件 git commit --amend -m 新的提交信息amend 的作用是把你当前暂存区里的内容合并进上一次 commit并生成一个新的提交哈希。也就是说上一次提交被改写成了另一次提交而不是新增一次“补充提交”。这非常适合本地分支上的提交整理能让提交历史更干净。但这个命令有一个前提上一次提交还没有被推到远程共享。如果已经 push 到 GitHub被别人 clone 过那 amend 就会产生分叉历史后面对齐很麻烦。强行覆盖远程需要 git push --force-with-lease这个操作只应该在确认不会影响协作时使用。我的习惯是push 之前完成所有 amend 整理一旦 push 出去就只用新的 commit 来修正不再改写历史。使用 amend 时也要注意它不只是改信息是连提交内容一起替换。如果你只想改 message什么都没 add也可以直接执行 git commit --amend -m new message。它不会删除工作区的修改只调整上次 commit 的快照。5.4 把 push 被拒绝non-fast-forward 怎么办这个错误在多人协作时太常见了。你本地改了代码准备 push结果远程分支已经有别人先推了新的提交历史分叉Git 会拒绝你的 push提示 Updates were rejected because the remote contains work that you do not have locally。正确做法不是强推而是先把远程新提交拉到本地合并再推送。常用两种方式git pull origin main git push origin maingit pull 默认会把远程分支 merge 到本地分支相当于先合并再推送。如果你本地几乎没有新的提交用 git pull --rebase 也可以保持直线历史。拉到最新后如果出现冲突按第 4.4 节的处理方式解决然后正常 push。强推是最后手段。除非仓库只有你一个人否则不要用 git push --force。因为强推相当于用本地历史覆盖远端历史别人的提交会被直接丢弃。真需要覆盖时用 --force-with-lease它只有在你认为的远端状态和实际一致时才会执行能降低一点风险。5.5 GitHub 访问变慢或 push 超时了怎么办从代码层面讲Git 不会无故超时。常见的两种诱因一是本机网络有问题二是从本机到 GitHub 之间的网络线路在高峰期容易出现延迟和丢包。判断方法很简单先用浏览器打开几个常用网站如果都卡问题在于本机网络如果只有 GitHub 响应慢那多半是跨地域线路的常见波动换个时间段再试往往会恢复正常。排查时可以执行git ls-remote gitgithub.com:user/repo.git这个命令只会在远程探测分支引用如果长时间不返回说明本机和 GitHub 之间的连接不太健康。这时候不要反复重试同一次 push更不要自作聪明地改一堆配置先做三件事刷新 DNS 缓存Windows 下执行 ipconfig /flushdns、确认当前网络连接正常、过几分钟再试。如果该项目是你个人项目也可以考虑把大文件提交拆小分多次推送减少单次传输的压力。有段时间我的仓库偶尔会在 push 时卡顿我一度以为是代码问题后来发现是本地网络路由抖动。冷静下来等一等问题自然就过了。如果企业内网还涉及额外限制那就先确认 443 端口是否放行这属于基础连通性检查和代码无关。5.6 Git LFS 相关报错和文件过大问题GitHub 对仓库里单个文件超过 100MB 时会直接拒绝 push。如果你误传了一个大文件最常见的报错是“this exceeds GitHubs file size limit”。处理分两步先把该文件从当前跟踪列表中移除并提交再把本地历史里的大文件清理掉。只是删除当前文件还不够因为历史提交里还留着那个大文件push 依然会被拒绝。便捷的方式是安装 git filter-repo 进行历史重写但对新手来说最重要的是防患于未然。养成在项目初始化时就把大文件相关路径写进 .gitignore 的习惯或者提前用 git lfs track 标记好大文件后缀。我在涉及游戏素材、测试数据的项目里会在第一笔提交时就把.psd、.zip、*.mp4 全部交给 LFS 管理后面基本没再为文件过大发过愁。6. 给新手的工作流建议和我的几个私人习惯6.1 每天开工和收工的固定动作早上到工位先不要在本地闷头改代码先把远端状态同步下来git fetch --prune origin git pull origin mainfetch 不会改动本地工作区只是把远端信息取回来pull 会把 main 的新提交合到本地。--prune 会清理远端已经删除的分支的本地跟踪记录避免分支列表越攒越乱。收工之前不管代码改到哪一步先看一下 git status把有效改动提交否则第二天很容易丢失上下文。这一步看似简单却能让工作节奏非常清晰。很多分支合并问题本质都是本地长期不 pull导致提交历史越分叉越远最后一下冲突特别大。每天同步一次能显著减少这种“历史鸿沟”。6.2 提交节奏和提交信息怎么写提交频率不要走极端既不要三天一次大提交也不要每改一行就提交。比较合理的节奏是一个功能点完成后提交一次文档改动单独提交bug 修复单独提交。这样后续合并代码时能够很容易找到某一次具体改了什么。提交信息建议按约定格式写比如fix: 修复登录超时问题、feat: 增加导出功能、docs: 更新部署文档。好处是合并分支时扫一眼就能知道每个提交是干什么的。我们可以夸张一点地说规范提交信息不是给 GitHub 看的是给两周后的自己看的。很多次我回看旧项目都是靠清晰提交信息才快速定位到改动位置的。6.3 合并前的一点小仪式感在把 feature 分支合并进 main 之前我会强制自己多做一个动作先在 feature 分支上执行一遍 git status确认没有未提交的修改然后把当前分支切到 main执行 git pull 更新本地 main 到最新最后再 merge。这一套不超过两分钟但能避免“我以为我 merge 的是最新代码其实本地 main 已经很旧”的尴尬。另外合并完成后先不要急着删 feature 分支等 push 成功并在 GitHub 上确认无误后再删远端分支也不迟。删除本地分支用git branch -d feature/add-log如果分支没有合并Git 会拒绝删除这是保护机制。真要强行删除才需要 -D。我很少用 -D因为这通常意味着有提交会丢失。踩过这么多次坑之后我最深的体会是Git 本身并不复杂复杂的是人总想跳过中间步骤。上传文件到 GitHub 指定文件夹看着像传输问题本质是目录管理和提交记录问题分支合并看着像命令问题本质是对历史分叉的理解问题。只要每次动手前先看一遍 git status每次 push 前想清楚自己提交的是什么这套流程会可靠很多。最后再分享一个小技巧在本地仓库里永远保持 main 分支是能跑的版本所有未完成的工作都在分支上进行等合并时再用第 4 节那套流程把功能安全地汇入主线。用不了多久你就会发现这些操作已经不需要思考了。