★ FEATURED ARTICLE GitHub几乎是现在开发者绕不开的一站但很多刚接触的人卡在的不是写代码而是怎么把文件放到指定文件夹和怎么把分支合并回主分支这两件事上。尤其当你跟别人协作一个项目或者想把某次修复提交到仓库里某个特定目录时操作不熟悉就特别容易把仓库搞得乱七八糟。这篇文章我不讲高深理论就围绕上传文件到GitHub指定文件夹和分支合并这两条主线把网页端、命令行、桌面客户端三种方式全部走一遍顺带把合并过程中最常见的冲突和踩坑点一次说透。适合刚开始用GitHub、或者用了很久但一直只会在网页上点来点去的人。1. 先把GitHub的底层逻辑捋清楚仓库、分支和指定文件夹到底指什么很多人一上来就急着点Upload files结果文件全堆在根目录时间一长仓库乱得自己都找不到东西。想精确把文件送进指定目录第一步不是学命令而是理解GitHub这一个仓库里同时存在三套空间文件目录树、分支、提交历史。1.1 仓库就是一个云端的大档案柜GitHub上的每个仓库repository你可以理解成一个档案馆里面所有文件按目录层级摆放。这个档案馆不只存着当前这份文件还存着每次修改的快照也就是commit提交记录。每提交一次相当于给整个目录拍了一张照片随时可以退回去查看或者恢复。所以上传文件到指定文件夹这件事本质上是两层操作第一文件在目录树里的位置要正确第二这次新增改动要形成一次commit落到某个分支上。很多人上传之后发现文件不知去向大概率就是这两个环节其中一步出了问题。1.2 分支是同一仓库里的平行工作台分支branch是这一整套Git设计里最聪明的部分。它像同一档案馆里开辟的多个独立工作台每个工作台都有自己完整的一套文件快照。你在自己的分支上随便改、随便传都不会影响到主分支的文件内容。默认情况下仓库会有一个主分支现在GitHub新建仓库默认叫main老一点的项目可能叫master。大多数人操作的主战场就是它。之所以要有分支是因为多人协作时如果所有人都直接在主分支上做修改今天你覆盖我、明天我覆盖你根本没法干活。分支提供了一条先各干各的再统一汇总的路径。1.3 所谓指定文件夹其实只是仓库里的目录路径Git并不区分文件和文件夹这两个概念它只认识路径。也就是说你想把report.pdf放进docs/财务报告/2025/这个目录你要做的只是让这个文件在提交时处于这个路径之下。在网页上传时你需要先点进目标文件夹再做上传操作在命令行里你需要把文件放在仓库本地对应路径下再git add。理解了这一点后面所有操作就都好理解了——一切上传行为的本质都是把文件放到某条路径下然后提交到某个分支。2. 三种把文件放进指定文件夹的办法总有一款适合你上传方式常见的有三种网页端直接拖拽、命令行git push、GitHub Desktop客户端。我平时会混着用零星小改动走网页批量文件走命令行需要看差异对比时用Desktop。下面把每种方法都拆开讲。2.1 网页端上传零门槛适合小文件和临时提交网页端适合传小文件国际惯例建议100MB以内超过50MB最好悠着点尤其是图片、文档这类单个体积不大、数量不多的情况。操作步骤很简单打开仓库主页先点进你要上传的目标文件夹。如果目标文件夹还不存在就点根目录里的Add file下拉菜单选择Create new file在文件名输入框里把路径一次写完比如输入docs/财务报告/2025/README.mdGitHub会自动帮你创建中间目录。进入目标文件夹后点击Add file→Upload files。把本地文件拖拽进网页区域也可以点选择文件按钮。页面下方会有一个Commit changes区域输入一句提交说明比如上传第一季度财务报告。注意这里有个分支选择框默认是当前所在分支。确定无误后点击绿色Commit changes按钮。这套操作全部是图形界面基本不会出错唯一要提醒的是上传前务必看一眼页面左上角你停留在哪个分支、哪个文件夹我已经见过太多人一路点进根目录就传最后文件全堆在根路径下。2.2 命令行推送一劳永逸适合批量操作和日常开发命令行是最能发挥Git全部能力的方式。它没有文件数量和大小上限的界面限制也适合反复迭代提交。核心流程可以拆成六步# 1. 把远程仓库克隆到本地 git clone https://github.com/用户名/仓库名.git # 2. 进入仓库目录 cd 仓库名 # 3. 创建或进入目标文件夹把文件放进去 mkdir -p docs/财务报告/2025 cp ~/Desktop/report.pdf docs/财务报告/2025/ # 4. 把文件加入暂存区 git add docs/财务报告/2025/report.pdf # 5. 提交生成快照 git commit -m 上传2025年一季度财务报告 # 6. 推送到远程分支 git push origin main这里有几个细节值得展开说。先看第4步。git add后面的路径可以是文件、文件夹也可以是.表示仓库内所有改动。如果你在仓库根目录执行git add .会把所有变动一起提交这是新手最爱用但也最容易误传的写法。所以尽量精确写路径这样即使出问题改动范围也小。再看第3步。命令行和网页端最大的不同在于你必须先把文件放进本地仓库对应的路径仓库外传不进去。如果你在仓库目录外执行git addGit会直接给你一句报错fatal: not a git repository (or any of the parent directories): .git这句话的意思是当前目录不是仓库或仓库的子目录拿到这行报错别慌检查一下自己所在位置就好。还有一点很容易忽略如果你要上传的是整个目录比如一个前端项目的build产物文件夹直接git add build/就行Git会把整个文件夹连同内部所有文件一起提交不需要逐个添加。提示首次使用命令行推送时如果提示配置用户名和邮箱执行git config --global user.name 你的名字和git config --global user.email 你的邮箱即可。建议邮箱和GitHub账号绑定的邮箱保持一致这样提交记录能正确对应到你名下。2.3 GitHub Desktop介于两者之间的可视化方案如果你不想记命令又需要比网页端更强的可控性GitHub Desktop是很好的过渡。下载安装后用账号登录依次点击File→Clone repository把仓库克隆到本地。之后所有操作都回归人们的直觉在电脑文件夹里把文件放进目标路径回到Desktop窗口左侧会自动显示有改动的文件列表底部会让你填Summary提交说明点击Commit to main生成提交再点击Push origin推送到远端。Desktop最大的好处是在点击提交之前你能清楚看到本次改动了哪些文件、每个文件改了哪几行这对防止把不该传的东西传上去特别有用。另外它左上角清晰显示当前所在分支切分支也只要下拉选择即可不容易出现在错误分支上操作这种事故。三种方式的适用场景我整理成了表格方式适合场景需要本地环境批量操作可预览改动网页端小文件、偶尔上传、不装本地环境否较弱无命令行批量文件、日常开发、精确控制路径是强有限GitHub Desktop不想记命令、想可视化提交是中等强3. 分支合并的完整链路从建分支讲到Pull Request收口文件成功上传之后如果都往主分支推迟早会撞车。规范的流程是新建一个分支在分支上做修改最后通过Pull Request简称PR把改动合并进主分支。下面把这条链路完整走一遍。3.1 为什么不能直接在主干上改这里要给新朋友一个直观的类比主分支相当于正式发布的报纸任何人拿到手里的版本都是一样的。如果你直接在报纸上涂改再印刷发行读者拿到手的就不一样了。分支则像一间编辑室大家各自在自己桌上改稿子改完经过审阅再由责任编辑统一排版发布。在这个流程里Pull Request承担的就是提交审阅这个环节。它不是一个复杂的操作本质是向仓库管理员提出请把我这个分支的改动合入主分支的申请。好处是第一改动在合并之前可以被其他人审查错误能提前发现第二合并历史清晰以后回溯时知道每个功能对应哪次PR第三多条分支并行开发互不干扰。3.2 建分支、提交、推送的标准操作网页端建分支很直接仓库页面上方有一个分支选择器点击后输入新分支名字回车就创建了。命令行则用一条命令搞定git checkout -b feature/upload-report这条命令的意思是创建一个名为feature/upload-report的新分支并切换过去。-b参数就是创建并切换的组合动作。接着在这个分支上正常做文件上传、git add、git commit最后推送时需要告诉Git我要把本地这个分支推到远程git push origin feature/upload-report第一次推送会提示你本地分支和远程分支的关联关系以后再次执行git push就可以了。推送完成后网页端仓库页面上方通常会弹出一个黄色或绿色的提示条写着类似Compare pull request这就是GitHub检测到你刚推送了新分支主动邀请你发起合并申请。3.3 Pull Request真正的合并发生在这里点进Compare pull request后会进入一个PR描述页。页面上方要确认合并方向通常是从你的分支合并到主分支也就是base: main←compare: feature/upload-report。这个方向一定要看清反了的话会把主分支的改动合到你的分支里逻辑就乱了。填写标题和描述把这次改动做了什么、为什么做、影响范围是什么写清楚然后点击Create pull request。之后仓库管理员或协作者会在PR页面进行讨论、留下评论意见如果确认没问题就点Merge pull request完成合并。合并方式有三种接口上对应的按钮分别是Create a merge commit保留所有提交记录生成一个合并提交。适合需要完整保留开发过程的情况。Squash and merge把分支上所有提交压缩成一条再合并。提交历史更干净适合功能分支。Rebase and merge把分支上的提交逐个移植到主分支上完全线性历史。要求分支没有冲突否则需要先处理。我个人的做法是团队成员多、开发周期长的项目用Squash and merge让主分支历史保持清爽每个功能只留一条记录个人小项目直接用Create a merge commit也无妨。合并完成后还要记得把远程和本地都同步一下。网页端合并完本地执行git checkout main git pull origin main这会让本地主分支跟上远程最新状态。如果你以后还要继续开发新功能一定要先拉取最新代码再开新分支否则容易基于旧代码开发平白增加冲突。3.4 在IntelliJ IDEA这类IDE里怎么合并分支如果你在JetBrains全家桶里开发比如IntelliJ IDEA其实不太需要记命令行。IDEA右下角可以看到当前分支名称点击它弹出分支操作菜单。想要把其他分支合入当前分支选择Branches里的目标分支然后点击Merge into Current即可。但需要提醒的是IDE的图形化合并虽然方便它在背后执行的就是git merge所以如果你对分支关系不熟还是建议先在命令行里用git log --graph --oneline查看一下分支走向心里有底再在IDE里操作。图形化工具能简化操作但不能替代理解。4. 冲突不是bug是Git的正常反馈处理冲突的完整流程合并过程中最让新手紧张的就是冲突conflict很多人一看到红字就以为仓库坏了。其实冲突是Git在保护你的数据它明确告诉你两个分支都在同一个位置做了修改我不知道该听谁的请你来决定。4.1 冲突是怎么产生的先给一个最小场景。假设主分支上有个README.md里面有一行# 项目标题。A分支把这行改成了# 电商平台后端B分支同时把这行改成了# 博客系统。当A分支已经合并进主分支后再合并B分支时Git就犯难了主分支现在是A的版本B分支是另一个版本两个版本都合法但只能保留一个。这就是冲突的本质同一文件的同一区域被两个分支各自修改且互不以对方为基础。有个非常直观的类比两个人同时往同一张表格的同一个单元格里填不同内容后填的人不能直接把先填的覆盖掉必须由表格的主人决定谁的内容有效。4.2 命令行处理冲突的详细过程当你执行合并时遇到冲突Git会终止合并操作并提示类似这样的文字Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result.此时别慌按下面的步骤处理。第一步打开提示冲突的文件你会看到特殊标记 HEAD # 电商平台后端 # 博客系统 feature/blog其中 HEAD到之间的内容是当前分支接收合并的一方的版本到 feature/blog之间是正在被合并进来的分支的版本。第二步手工编辑文件把不需要的内容删掉保留想要的同时删除这三行标记符号。比如最终决定用电商平台后端那文件里就只留一行# 电商平台后端一个文件里可能有多处冲突标记建议全文件搜索或逐个处理。第三步把处理完的文件重新加入暂存区然后提交git add README.md git commit -m 解决README标题冲突到这里冲突就算处理完成了。特别注意冲突提交完成后如果你查看合并状态不需要再执行git merge因为之前的合并操作已经被这次commit接着完成了。4.3 比解决冲突更重要的是预防冲突解决冲突是技能预防冲突是智慧。从我大量协作经验来看以下习惯能显著减少冲突出现频率每次开始新功能前先git pull把主分支最新代码拉到本地确保你基于最新状态开发。分支生命周期不要太长尽量小步提交、频繁合并。一个分支存活超过两周冲突概率会指数级上升。多人协作时尽量避免几个人同时改同一个文件。团队里可以约定大文件、公共文件由专人负责。代码格式化、目录结构调整这类全局性改动单独用一次commit、一条PR来做不要混进功能分支里。说到底Git只是一个工具冲突不是惩罚而是它认真工作的表现。处理过两三次冲突之后你就会发现这套机制其实非常合理。5. 实操中容易踩的高频坑上传与合并的翻车现场复盘最后这部分我整理了平时答疑和团队协作里见到最多的几个翻车场景每个都是真实案例希望能帮你少走弯路。5.1 文件传到了错误的分支这是一个非常经典的失误。有人在网页端上传文件时没注意当前所在分支是feature/test文件提交上去后切回main分支一看文件不见了以为数据丢了急得团团转。其实文件没丢只是在另一个分支上。解决思路有两种。如果文件本就该在主分支上最简单的方式是切到feature/test分支确认文件在然后在网页端对这个分支发起Pull Request合入主分支或者命令行里用git checkout main git cherry-pick把那次提交复制到主分支。如果文件根本不该存在直接在错误分支上删除文件并推送保持主分支干净即可。要避免这个问题上传前养成一个习惯先看页面上的分支选择器。这是网页上传最容易忽略的一个地方。5.2 本质是路径问题的上传到指定文件夹失败很多人反馈我在网页上传时明明进了某个文件夹传完之后文件却跑到根目录了。我遇到过类似的情况最后发现原因多半是操作时浏览器地址栏显示的URL已经切回了仓库根路径或者你在某个子页面上停留太久页面状态没刷新。网页上传的目录归属是跟随你进入的文件夹页面而定的不是跟随你上传时脑子里想的那个文件夹。另一个与之相关的坑是你想让文件进入一个尚不存在的多级目录但网页端Upload files本身不会自动帮你创建路径。解决办法是先用Create new file创建一个最里层的占位文件比如直接输入project/src/utils/placeholder.txt一次性创建多级目录之后再去这个目录里上传真正的文件最后把占位文件删掉。多一步操作但目录结构完全可控。5.3 中文文件名和乱码问题GitHub本身对中文文件名支持良好网页端上传显示中文完全没问题。但有些人在本地用命令行提交后在GitHub网页上看文件名是一串奇怪的八进制转义字符比如\346\225\260\346\215\256.md。这本质是Git为了兼容老系统做的转义显示。想看正常中文执行一次配置git config --global core.quotepath false从此以后git status和远程仓库都会正常显示中文文件名和中文路径。另外如果你需要在命令行提交信息里写中文直接在git commit -m 中文说明里写就可以不需要任何额外配置但前提是终端编码是UTF-8。5.4 大文件、隐藏文件和 .gitignore 的坑GitHub网页端单个文件超过100MB会直接报错拒收命令行推送时超过这个限制也会被远程拒绝。如果项目里用了大体积的模型文件、视频、数据库备份建议改用Git LFSLarge File Storage方案或者干脆不要把大文件放进Git仓库而是走网盘、对象存储之类的途径。很多人还会遇到一个尴尬场景本地项目的node_modules、.DS_StoremacOS系统隐藏文件、编译产物目录被一股脑推到GitHub导致仓库体积爆炸。正确做法是在仓库根目录创建.gitignore文件提前声明哪些路径不参与版本管理node_modules/ dist/ .DS_Store *.log这样执行git add .时上述文件和目录会被自动忽略。如果你已经误传了大文件或隐藏文件普通删除后历史记录里仍然保留着它们仓库依然臃肿。这时需要用到git filter-branch或git rm --cached等历史重写操作比较麻烦所以最好的防线还是最开始就配好.gitignore。最后分享一个小技巧我平时在团队里带新人时会让他们在个人仓库里专门建一个practice目录反复练习上传一个文件到指定文件夹 → 新建分支 → 修改文件 → 发起PR → 合入主分支 → 同步本地这整套动作。练三次以上基本就能形成肌肉记忆。如果你也经常在网页端和本地方案之间切换建议记住一句话网页端适合补命令行适合批Desktop适合看。多一种工具不是多一份负担而是多一条退路。哪天网页端抽风打不开本地命令行一样能把活干完这才是稳定工作者该有的底气。
阅读完成 · 觉得有帮助？
