企业官网建设流程全解析

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最好悠着点），尤其是图片、文档这类单个体积不大、数量不多的情况。

操作步骤很简单：

1. 打开仓库主页，先点进你要上传的目标文件夹。如果目标文件夹还不存在，就点根目录里的Add file下拉菜单，选择Create new file，在文件名输入框里把路径一次写完，比如输入docs/财务报告/2025/README.md，GitHub会自动帮你创建中间目录。
2. 进入目标文件夹后，点击Add file→Upload files。
3. 把本地文件拖拽进网页区域，也可以点选择文件按钮。
4. 页面下方会有一个Commit changes区域，输入一句提交说明，比如"上传第一季度财务报告"。
5. 注意这里有个分支选择框，默认是当前所在分支。确定无误后点击绿色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 add，Git会直接给你一句报错：

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最大的好处是，在点击提交之前你能清楚看到本次改动了哪些文件、每个文件改了哪几行，这对防止"把不该传的东西传上去"特别有用。另外它左上角清晰显示当前所在分支，切分支也只要下拉选择即可，不容易出现"在错误分支上操作"这种事故。

三种方式的适用场景，我整理成了表格：

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 LFS（Large File Storage）方案，或者干脆不要把大文件放进Git仓库，而是走网盘、对象存储之类的途径。

很多人还会遇到一个尴尬场景：本地项目的node_modules、.DS_Store（macOS系统隐藏文件）、编译产物目录被一股脑推到GitHub，导致仓库体积爆炸。正确做法是在仓库根目录创建.gitignore文件，提前声明哪些路径不参与版本管理：

node_modules/ dist/ .DS_Store *.log

这样执行git add .时，上述文件和目录会被自动忽略。如果你已经误传了大文件或隐藏文件，普通删除后历史记录里仍然保留着它们，仓库依然臃肿。这时需要用到git filter-branch或git rm --cached等历史重写操作，比较麻烦，所以最好的防线还是最开始就配好.gitignore。

最后分享一个小技巧

我平时在团队里带新人时，会让他们在个人仓库里专门建一个practice目录，反复练习"上传一个文件到指定文件夹 → 新建分支 → 修改文件 → 发起PR → 合入主分支 → 同步本地"这整套动作。练三次以上，基本就能形成肌肉记忆。

如果你也经常在网页端和本地方案之间切换，建议记住一句话：网页端适合"补"，命令行适合"批"，Desktop适合"看"。多一种工具，不是多一份负担，而是多一条退路。哪天网页端抽风打不开，本地命令行一样能把活干完，这才是稳定工作者该有的底气。