企业官网建设流程全解析

1. 先想清楚：上传文件夹，到底是在传什么

1.1 Git和GitHub不是一回事，很多人第一步就理解偏了

看到标题“Github上传文件夹”，我猜你多半是把课程作业、项目代码或者一整个工作目录带到GitHub仓库页面上，结果发现怎么拖都拖不进去，或者拖进去了目录结构乱成一团。这个场景我在技术社群里见了不下一百次，所以这篇直接讲清楚上传文件夹的所有可行路子，以及每一步背后的逻辑。

先把这个最基础的概念掰开讲：Git是版本控制工具，GitHub是基于Git的代码托管平台。你把文件夹“传上去”，本质上不是单纯把文件复制到网页，而是让本地的一个目录纳入Git的版本管理，再把整套版本记录推送到远程。这也是为什么网页端拖拽上传在老手眼里只算应急手段——它只是把文件放上去了，没有任何提交历史、分支信息、版本记录。如果你的文件夹里本来就有一个隐藏的.git目录，用网页拖拽上传等于把这些历史全部丢光。

我还见过不少人把整个项目文件夹直接拖上去，连带node_modules、dist、target这种几百兆的依赖和构建产物一起传。传得慢不说，仓库体积瞬间膨胀，别人clone下来苦不堪言。所以在点击任何按钮之前，你应该先搞清楚：这个文件夹里哪些内容该传、哪些不该传，这才是整个上传操作里真正决定成败的部分。

1.2 两条路线：网页拖拽和命令行推送，分别适合什么人

根据我长期观察，想上传文件夹的人其实分成两类。第一类是课程作业、实验报告、学习笔记、静态网页这类一次性内容，文件夹不大、不需要版本历史，也不想学任何命令。这类人走Web端拖拽最合适，两分钟搞定，零学习成本。第二类是真正做项目的人，哪怕只是自己练手的小工具，也希望以后能记录每次改动、能回滚到任意版本、能和其他人协作。这类人无论如何都应该用命令行走完整的git push流程。

很多人觉得命令行的学习成本高，其实真正高频用到的命令就那么五六个，git init、git add、git commit、git push这四个动作背下来，你就已经迈过了Git的第一道门槛。完整执行一次之后，你会发现它比网页拖拽更像“正经操作”，因为每一步都在明明白白地告诉你：现在暂存了什么、提交了什么、要往哪里推。后面我会把两条路线分别完整走一遍，你按自己的情况选一条就行，但我的建议是，哪怕你这次先用网页拖拽应急，也尽量花半小时把命令行路线学一遍，这笔时间花得值。

2. 最快路径：Web端直接拖拽上传文件夹

2.1 操作步骤：从新建仓库到拖拽上传

Web端上传文件夹这件事，核心流程只有三步：建仓库、进上传页、拖文件。先登录GitHub，右上角头像旁边的加号点开，选择New repository。仓库名建议用英文小写加短横线，比如my-project，不要用中文，也不要以下划线开头，这对以后生成的老练链接和阅读体验更友好。公开还是私有，建议新手一律选Private，尤其是课程作业和学习笔记，避免把隐私内容不小心挂到公网上，后面再改可见性虽然也能改，但没必要给自己找这个麻烦。

创建完仓库后，默认页面会看到“uploading an existing file”这个入口，点进去就是拖拽区域。把整个文件夹直接拖进这个区域，GitHub会自动保留文件夹的相对路径结构。你拖进去一个叫docs的文件夹，里面有三层子目录，传完之后目录结构会原样保留。文件上传完成后，在下方的Commit changes区域填一条提交说明。默认文字是“Add files via upload”，我建议改成人话，比如“上传课程项目完整代码”，以后回看记录时能一眼看出这个版本做了什么。填完点击Commit changes，上传就完成了，回到仓库首页就能看到完整的目录树。

这里有个细节要特别提醒：Web端单文件大小上限是100MB，超过100MB会直接失败，超过50MB会收到警示提示。如果你要传的是实验数据、模型权重、视频素材，别硬拖，老老实实走GitHub Releases或者Git LFS。另外，单次上传的文件数量也别贪多，上百个文件时浏览器请求很容易超时，表现为传到一半转圈圈然后失败。我的建议是一次传几十个以内，内容太多就拆几次传。

2.2 一个容易踩的坑：空文件夹不会被上传

这个坑几乎是所有新手都逃不掉的。你辛辛苦苦搭好了项目目录结构，里面有些文件夹是空的，比如用于存放日志的logs目录、用于存放临时文件的tmp目录，结果拖上去之后，浏览器看着是传完了，刷新一看，这些空文件夹全都不见了。

这不是GitHub的Bug，而是Git本身的设计：Git永远只跟踪文件，不跟踪空目录。目录本身不是Git的版本对象，只有当目录里有文件时，Git才会记录这个目录路径。所以只要你用Web端上传，空文件夹必然会丢；哪怕用命令行git add .，空目录同样不会被加进版本库。

解决办法简单到不像个专业技巧：在空文件夹里放一个占位文件，命名约定俗成叫.gitkeep。这个文件什么都不用写，内容为空就行，它的存在等于告诉Git“这个目录是故意建的，请保留它”。放好之后再上传，目录结构就不会丢了。这个手法看着朴素，但你在很多知名开源项目里都能看到它的身影，属于那种“会的人觉得理所当然、不会的人卡半天”的小知识。

3. 正经路子：用命令行把整个文件夹推上去

3.1 完整命令序列与每一步的含义

假设你已经在GitHub网页上建好了一个空仓库，仓库链接类似用户名/仓库名.git，现在你要把本地文件夹正式推上去。打开终端，进入项目目录（Windows是cmd或PowerShell，macOS是Terminal，Linux随便什么终端都行），然后依次执行下面这组命令。

git init git add . git commit -m "第一次提交" git branch -M main git remote add origin https://github.com/你的用户名/你的仓库名.git git push -u origin main

逐条拆开解释。git init会在当前目录生成一个隐藏的.git文件夹，你的全部版本历史都存在这里。如果你的项目目录里已经有一个.git，说明之前初始化过了，这句可以跳过。然后是git add .,把当前目录下所有文件加入暂存区，点号代表当前目录；你也可以精确一点，git add src只添加src目录。接着git commit -m "第一次提交"，把暂存区固化成一次正式版本记录，引号里是提交说明，建议从第一次开始就写清楚这次提交做了什么。

接下来 git branch -M main，把当前分支改名为main。这是GitHub在2020年后默认分支策略调整之后的通用做法，以前默认叫master。不改的话，推送时可能因为分支名不一致各种别扭，所以干脆一上来统一成main。然后是git remote add origin 远程仓库地址，把本地仓库和远程仓库关联起来，origin是远程仓库的别名，业界约定俗成，不用改。

最后一条git push -u origin main，把本地main分支推送到远程。这里的-u参数意为建立本地分支和远程分支的追踪关系，以后你只要敲git push就能直接推送，不用再带参数。首次推送完成后，回到GitHub网页刷新，你就会看到完整文件夹结构和第一次提交记录，整个流程清晰可控，和网页拖拽完全是两种体验。

3.2 用户认证部分：为什么密码登不上去了

新手用命令行推送时，几乎都会卡在认证这一步。你在git push后输入用户名密码，结果一直提示认证失败。这不是你操作错了，而是从2021年8月起，GitHub正式停止了对账号密码的认证支持，以后用账号密码push必然报错。

现在的正统做法是用Personal Access Token，你可以把它理解成一把有期限、可随时撤销的仓库钥匙。申请入口在：右上角头像 → Settings → 左侧栏里的Developer settings → Personal access tokens → 点击Generate new token。生成时一定要勾选repo相关的权限范围，不要只选个read权限就完事。Token只会在页面上完整显示一次，生成之后立刻复制保存，丢了就只能重新生成。

执行git push后，Git会弹出认证窗口，用户名填你的GitHub账号，密码位置粘贴这一长串token，而不是账号密码。第一次试通后，你会觉得token这玩意儿比密码麻烦多了，但它的好处是：可以设置有效期、可以随时作废、可以只授权特定仓库，安全性远胜账号密码。

这里再给一个进阶配置：如果你在自己的电脑上频繁推送，每次输token非常恼火，可以在终端执行git config --global credential.helper store，它会把认证信息保存到本地，第一次输入后后续自动携带。这个方法也有代价——凭证以明文形式存在本地，只建议在个人电脑上用。如果你在实验室公共电脑或者公司共享电脑上操作，千万别这么配，泄露风险太大。

3.3 让小白也能看懂的三步原理：快递网点、推车和快递单

很多人第一次接触git add、git commit、git push三个命令时，会觉得很抽象。我习惯用一个生活化的例子来解释，把它想成发快递的全过程。git init是注册一个快递网点的账号；git add是把你要寄的东西全部搬上推车，推车上放的是“暂存区”，这一步告诉你哪些东西准备好要寄了；git commit是打包封箱、贴上快递单，把推车上的东西固定成一个包裹；git push是把包裹交给快递员，送到GitHub这个远程仓库网点。

为什么不一步到位直接传？因为Git的设计者希望你每一步都有反悔的机会。git add之后，你发现不小心把不该传的文件放进来了，可以用git rm --cached把文件从暂存区撤下来，本地文件不会受影响。git commit之后，你发现提交说明写错了，可以用git commit --amend修改本次提交信息。分阶段操作意味着每一层都有撤销和调整的空间，这是Git作为版本控制工具最核心的设计理念。理解了这一点，后面再学分支、合并、回滚这些高级操作，思路会顺很多。

3.4 什么时候不能直接push：大文件、敏感文件与.gitignore

命令行虽好，但也不能一顿操作猛如虎，把不该传的全推上去。我见过不少事故现场：有人把.env环境配置文件传上去，里面躺着数据库密码、API密钥，整个仓库等于裸奔；有人把好几个G的视频素材也传上去，仓库体积爆炸，后续每次clone都让人崩溃。

先记住三条红线。第一，单个文件不超过100MB可以直接推，超过50MB Git会给你提示，超过100MB直接拒绝。要处理大文件，用Git LFS或者放GitHub Releases，LFS适合需要跟仓库一起管理的大文件，Releases适合安装包、压缩包这类发布物。第二，私密信息一律禁止提交，.env、.pem、任何包含密码和密钥的配置文件都不能出现。第三，依赖目录和构建产物不要入库，node_modules、dist、target这些别人clone下来后执行一次构建就能重新生成的东西，不该躺在仓库里。

守住这些红线靠.gitignore。在项目根目录创建这个文件，一行一条忽略规则，把不该提交的目录和文件写进去：

node_modules/ dist/ .env *.log .DS_Store

先写好.gitignore再执行git add .，这个顺序很重要。如果你已经不小心把node_modules提交进去了，也不是没救，执行git rm -r --cached node_modules把它从Git跟踪列表里移除，再commit一次。文件仍然保留在本地，只是不再被上传。这个清理误提交的技巧在后续项目维护中非常实用，建议提前收藏。

4. 上传过程中最常见的报错与排查实录

4.1 高频错误与解决对照表

上传文件夹这个操作看似简单，实际各种报错层出不穷。我整理了一份高频问题对照表，每个问题后面都附上实测可行的处理办法。这张表不敢说覆盖所有情况，但能覆盖绝大多数新手上传场景。

这里单独说最后一行的场景。很多新手执行完git commit直接push，结果提示分支不存在，原因往往是commit之前忘了git add，导致实际上根本没有任何提交生成。此时执行git log看输出是否为空，一眼就能判断。类似这种问题，排查思路比背命令更重要：先确认本地到底有没有提交，再确认分支名，最后才去怀疑远程配置，按这个顺序排查，大部分问题都能解决。

4.2 一个先应急后梳理的组合拳与一个长期习惯

除了报错对照表，我再分享两个自己实际用下来的心得，能帮你规避很多隐形麻烦。

第一个心得是“先应急，后梳理”的组合拳。如果你对命令行还不熟，又必须马上把文件夹传上去给某个人看，可以分两步走：先用Web端拖拽上传把文件传上去应急，保证内容立刻可见；然后腾出时间，在本地执行git init初始化，再用git clone把远程仓库拉下来，把拖拽上传的内容变成一次正式的commit记录。这样既解了燃眉之急，又补全了版本历史。我帮同事处理紧急场景时经常用这个组合拳，两边都不耽误。

第二个心得是提交信息里永远写清楚“为什么”。新手最容易写出“update”“fix”这种毫无信息量的提交说明，三个月后回看，根本想不起来当时改了什么。我建议提交信息带上具体内容，比如“完成登录页布局并修复移动端错位”，哪怕多敲几个字，对后续排查问题和代码回溯都有巨大帮助。这个习惯从你第一次commit开始养成，时间越久收益越大，协作时别人也会觉得你很专业。

5. 上传之外：从热词看GitHub使用的几个真实场景

5.1 拿到一个GitHub项目，五分钟判断值不值得学

有人搜索“github项目评估”，我猜是刷到某个项目，想知道它值不值得研究。关于怎么快速评估一个GitHub项目，我有自己的一套判断标准。

第一眼看README。README是项目的说明书，写得认真不认真，基本决定了项目维护者的靠谱程度。安装步骤、使用方法、目录结构、常见问题都写得明明白白，这个项目大概率靠谱。如果README只有一句含糊描述，或者README里的英文都拼写错误成片，那后续文档和代码的质量很可能同样粗糙。

第二眼看星标数，但不要把它当唯一标准。星标高说明关注的人多，不代表代码质量高，更不代表适合你学习。真正值得关注的是三个数据：最后一次commit时间，超过一年没更新说明项目可能已经停摆；open issue的数量和维护者回复情况，issue堆积且无人回应，说明维护者已经放手；release页面的规范性，有release说明作者会发布版本、维护版本号，这种项目更有生命力。

判断一个项目合不合适自己，还要看技术栈和目标是否匹配。比如机器人遥控一类的项目，依赖ROS2生态，需要配套硬件，明显不适合零基础学习者拿来起步。这类项目更适合先读README和架构文档，理解它解决什么问题，而不是急着跑起来。想找练手项目，我更推荐去GitHub官方Skills页面或者搜awesome-xxx系列列表，那里收录的都是经过社区筛选的高质量入门资源。

5.2 从“上传文件夹”到“我的主页”：GitHub还能怎么玩

当你终于弄懂怎么上传文件夹，你会发现GitHub能做的事情远不止“存代码”。最经典的玩法之一是部署个人博客：用Hexo这类静态博客生成器，在本地写文章，执行hexo generate生成静态页面，然后通过git push把生成目录推送到gh-pages分支，GitHub Pages会自动发布成网站。整个过程完全免费，不用买服务器。你每次写完新文章，本质上只是执行一次git push，发布流程自动化程度非常高。

另一个玩法是把GitHub当成自己的作品集。很多团队招聘时看重GitHub主页，不是因为仓库规模有多大，而是它能在一定程度上证明你在持续输出、有工程习惯。养成把自己写的工具脚本、学习笔记、小型实验项目都整理成仓库推上去的习惯，日积月累，主页上的提交记录就是一份真实的个人成长档案。从“上传文件夹”这个小目标起步，慢慢你会发现，GitHub带来的不只是代码存储空间，而是一整套能倒逼你规范做事的工程思维。

写到最后，我想分享一个自己踩过好多次坑之后的体会。刚开始用GitHub时，我也沉迷网页拖拽的方便，点几下鼠标把文件夹传上去，觉得这事就算完了。后来有一次，一个项目因为误传了包含第三方密钥的文件，不得不把整个密钥作废，从那以后我才真正意识到：上传文件夹从来不是“把它弄上去”的问题，而是“知道自己在把什么送出去”的问题。现在我每次push之前都会多花30秒看一遍git status，确认没有意外文件再commit。这个习惯救了我很多次。希望你看完这篇，也能先把这份谨慎装上，再动手传自己的文件夹。