企业官网建设流程全解析

看到标题里的"Day2"，有经验的朋友大概能猜出节奏：Day1通常是注册账号、安装Git、把环境磨到顺手，真正把本地代码规范地提交到远端仓库，是第二天才该认真做的事。这篇我就聚焦"代码提交至AtomGit平台自建公开仓库"这条主线，把从仓库规划、平台建库、本地Git配置到首次push的完整链路拆开讲，同时把我在实操中踩过和见过的坑一并交代清楚。文章适合两类人：一类是刚接触Git、想找一个国内访问稳定的代码托管平台练手的新手；另一类是准备把学习项目、小工具开源出来，需要一个公开展示仓库来承载作品集的开发者。

我尽量不绕弯子，按实际操作顺序讲，每一步都说明"为什么要这么做"。因为Git这种工具，光会敲命令没有用，理解每一步的意图才能举一反三。

1. 为什么第二天才推送代码：公开仓库先把规划做在前面

1.1 从"本地文件"到"远端仓库"，差的不是命令而是规划

很多新手拿到Git的第一反应是：把文件夹拖进去，commit一下，push上去，完事。真这么做的人，后面大概率要返工。Day1如果把安装和注册做完，Day2真正该花时间的，不是敲那几条命令，而是想清楚三件事：

第一，这个仓库放什么。是纯代码项目、随笔笔记、配置文件备份，还是特定的小工具集合？公开仓库的访问域名和项目主页会长期存在，最好一开始就给仓库定一个明确的边界。不要搞一个叫"test"的仓库，今天丢一段爬虫，明天丢一个简历，后天再扔一个论文模板，时间长了连你自己都找不着东西。

第二，目录结构需不需要整理。代码仓库讲究"从根目录开始就是项目内容"，而不是把整个桌面压缩包拖进去。比如一个Python项目，根目录应该有README.md、requirements.txt或pyproject.toml、源码目录、测试目录；一个前端项目应该有package.json、src目录、public目录。头部没有结构的仓库，别人点进去第一眼就失去兴趣。

第三，要不要携带历史提交记录。如果是全新项目，本地直接提交干净利落；如果是从别处拷贝来的代码，别把一堆无意义的临时提交记录带进公开仓库。公开仓库的commit历史就是你的技术脸面，整理成几个有逻辑的提交，比三百条乱七八糟的"update"要有说服力得多。

1.2 公开仓库不等于随便仓库

自建公开仓库意味着任何人都能浏览、克隆、fork你的代码。这个"公开"属性有巨大的好处——作品展示、协作开发、接收反馈、沉淀个人技术品牌，但它也有一条硬底线：凡是不能暴露的内容，永远不要推上去。

具体来说，这四类内容我建议默认拉黑：

• 密钥类：数据库密码、API Key、Token、私钥文件、.env文件。
• 个人隐私：本机用户名、真实姓名路径、内网IP、手机号、邮箱地址（如果不想被爬虫扒）。
• 大体积二进制文件：超过50MB的压缩包、模型文件、视频、安装包。Git不是网盘，公开仓库里的历史大文件会拖垮所有人克隆的效率。
• 依赖产物：node_modules、target、pycache、dist、build这类可以直接从源码重新生成的内容。

你可能会想"那我不提交不就行了"——但危险恰恰在于，很多人把文件已经commit进历史了，之后才发现要删。Git的提交历史是完整的，你在最新版本里删掉某个文件，并不代表它在历史记录中消失。任何看到这个仓库的人，用一行git log --diff-filter=D --name-only --oneline就能把删除的文件PATH捞出来。公开仓库在这件事上尤其凶险，因为它连"权限"这层保护都没有。

所以我给Day2定的第一个规矩就是：推送之前先写.gitignore，先把敏感文件挡在门外。这比推送之后再去填坑省心一百倍。

2. AtomGit建库实操：可见性、初始化模板与分支名确认

2.1 新建仓库时的关键选项一个都不能漏

AtomGit的注册流程很简洁，收个验证邮件就能用了。登录之后找到"新建仓库"的入口，会看到一个仓库配置页，这里有几个字段需要逐项确认。

仓库名称：小写字母、数字、中划线是主流风格，例如blog-backup、tools-scripts、my-first-open-source。不要用空格，也不要用中文命名，远端URL和本地克隆都会别扭。

仓库描述：建议认真写一句话。这句话会显示在仓库列表和个人主页上，别人判断要不要点进来看，全靠这个摘要。好的描述格式是"项目是做什么的 + 核心特色 + 技术栈标签"，比如"基于Python的批量图片压缩工具，支持WebP/PNG/JPEG格式，零配置命令行使用"。

可见性选择：这是最关键的一步。题目要的是公开仓库，就把可见性选为"公开"，同时在旁边确认一下公开的含义：代码和提交历史对所有人可见，不登录也可以克隆。如果选了私有，即使push成功了，别人也看不到，那就违背了"自建公开仓库"的本意。

"初始化仓库"选项组里面，通常会有几个复选框，常见的是自动创建README、自动生成.gitignore、添加开源许可证。我建议第一次操作时先全部勾选，让平台生成一份标准骨架，原因后面会讲。

2.2 分支名确认：这个细节决定你push顺不顺

AtomGit创建仓库时，平台会自动生成一个初始提交，同时创建默认分支。不同版本的平台默认分支名可能不一样，有的叫master，有的已经改成main。这个信息在仓库创建完成后的首页里能看到，通常在"分支"或"代码"标签页的左上角。

这一步很多人漏看，结果本地git init默认分支是master，远端分支是main，第一次push就撞出error: src refspec master does not match any或者推送上去后出现两个分支，主干和默认分支错位。其实解决起来也不难，但提前花十秒钟确认分支名，完全可以避免。

创建好仓库后先别着急关页面，把下面三个信息记下来：

• 仓库的HTTPS地址（形如https://atomgit.com/你的用户名/仓库名.git）
• 仓库的SSH地址（形如git@atomgit.com:你的用户名/仓库名.git）
• 默认分支名（master或main）

这三个信息，等会儿本地配置都要用到。

2.3 平台初始化模板的隐藏价值

平台上勾选"自动创建README"、"自动生成.gitignore"，看起来像是新手才会用的功能，很多老人会建议你全部取消，然后本地推一个干净仓库上去。但我实际上更建议第一次就勾上，原因有三：

第一，README和.gitignore由平台生成，可以确保远端仓库有一个最小的完整结构。本地如果还是一片空白，克隆下来直接开干就行，不用对着空仓库发呆。

第二，平台生成的.gitignore模板基于常见技术栈，覆盖了主流语言的忽略规则。比如你选了Python，它会自动忽略__pycache__/、*.pyc、venv/、.env等，比自己从零写要省事。

第三，平台生成的初始提交会建立一个远端主干，本地push时只要在这个主干上追加提交即可，不容易出现"两个完全无关的历史合并"这种处理起来比较麻烦的情况。

如果你的需求很明确，本地已经有完整项目了，那也可以不勾选这些模板，直接把本地仓库推到一个空仓库里。两种路径都能走通，但作为Day2的教程，我推荐采用"平台先生成骨架"的方式，因为后续遇到冲突的概率更低。

3. 本地Git环境准备：安装、身份配置和远程通道选择

3.1 Git安装的三平台对照

这一步大多数人在Day1已经做完了，如果你还没装，这里给一个可直接照做的对照表。

装完之后，在一个终端里执行git --version，能输出版本号就说明安装成功。我见到过不少人装完不验证，然后卡在"git: command not found"这种问题上一脸懵。其实这步比想象中重要。

3.2 全局身份配置和换行符处理

安装好Git后，第一件事是配置全局身份，不是建仓库，也不是拉代码。因为Git的每次提交都会打上"作者"标签，这个标签来自user.name和user.email，如果没有配置，提交时会报错或者弹出奇怪的提示。

git config --global user.name "你的用户名" git config --global user.email "你的邮箱"

user.name不一定要用真实姓名，但建议和AtomGit上的用户名保持一致，这样提交记录头像和主页信息能对应上。user.email如果要保护隐私，AtomGit等平台一般支持配置隐私邮箱，但刚上手阶段直接用常用邮箱就行。

这里还有一个很多人不知道的坑：换行符（line ending）。Windows下文本文件默认用CRLF（回车+换行）结尾，Linux和macOS通常用LF（换行）结尾。Git为了跨平台协作，提供了一个自动转换机制，叫core.autocrlf。

如果在Windows上安装Git时一路点默认，这个选项往往被设置为true，也就是提交时自动把CRLF转换成LF，检出时再转回CRLF。看起来挺智能，但如果你用一个老项目或者写脚本时文件编码不统一，可能出现"我明明只改了一行，git diff却显示整个文件都变了"的诡异情况。原因就是Git发现整个文件的换行符都被重新处理了。

我的建议是：个人项目、公开仓库能保持简单就保持简单。Windows用户把它设置成input，让Git在提交时统一转成LF，检出时不要乱动原始换行符；macOS/Linux用户保持默认即可。

git config --global core.autocrlf input

如果项目里已经有明确的换行符规范（比如团队约定强制LF），更优雅的做法是在仓库根目录放一个.gitattributes文件，把这个项目内部所有文件的换行规则固定下来。不过Day2这个阶段，设置好core.autocrlf就够用了。

3.3 HTTPS还是SSH：两条通道的取舍

Git往远端推送代码，核心就是两条通道：HTTPS和SSH。它俩都能完成代码提交，但使用体验差别很大。

HTTPS方式最简单，clone地址就是浏览器里那个链接，push的时候需要输入AtomGit的用户名和密码（或访问令牌）。适合临时用一下、换机器比较频繁的场景。缺点是每次push都要验证身份，虽然可以配置凭据缓存，但工作中时不时卡一下"输入用户名密码"也挺烦。

SSH方式需要提前生成一对密钥：私钥留在本地，公钥配置到AtomGit账号里。之后push就不需要再输密码了，安全性和便利性都更好。对一个要长期维护的公开仓库来说，我强烈建议直接走SSH。

生成密钥的命令：

ssh-keygen -t ed25519 -C "你的邮箱"

执行之后一路回车即可，会在~/.ssh/目录下生成两个文件：id_ed25519（私钥）和id_ed25519.pub（公钥）。注意私钥文件的权限不能太开放，Windows下一般不用管，Linux/macOS如果提示权限问题，可以执行chmod 600 ~/.ssh/id_ed25519。

查看公钥内容：

cat ~/.ssh/id_ed25519.pub

把输出的整行内容复制出来，粘贴到AtomGit的"个人设置-SSH公钥"或"安全设置"里，保存即可。

我个人对两条通道的建议是：如果你准备长期维护这个公开仓库，第一天就配置SSH，省掉后面所有密码输入环节；如果你只是临时提交一两次验证流程，用HTTPS也无妨，但记得把访问令牌妥善保存，别明文堆在桌面。

4. 首次提交全流程：从git init到公开仓库可见的完整链路

4.1 本地仓库初始化与第一次提交

现在远端有了一个带README和.gitignore的公开仓库，本地也装好了Git、配好了身份，接下来就是真正的"代码提交"环节。我这里给出两个入口，你可以根据自己的情况选一个。

入口一：远端仓库刚创建，带了平台生成的初始提交，本地还是空的。这种情况最省事，直接clone下来在副本里操作：

git clone https://atomgit.com/你的用户名/仓库名.git cd 仓库名

这会把远端仓库完整拉下来，本地自动建立master或main分支，并且默认设置好远程跟踪。之后你在这个目录里新增、修改文件，然后走add-commit-push流程即可。

入口二：本地已经有一个项目目录，想和这个新的公开仓库关联起来。这种情况操作步骤多一些：

cd /path/to/your/project git init git remote add origin https://atomgit.com/你的用户名/仓库名.git

如果远端仓库已经有初始提交（README等），先执行一次git pull origin master或git pull origin main把远端的骨架拉下来，再开始添加自己的文件，这样两边历史能平滑衔接。如果远端是空仓库，直接add-commit-push就行。

把项目文件加入暂存区之前，先确认.gitignore已经覆盖了该忽略的目录。如果平台生成的是Python模板，而你实际项目是Node.js，最好把node_modules、dist、.env等规则补进去。一个标准的.gitignore示例（前端项目）：

# 依赖目录 node_modules/ # 构建产物 dist/ build/ # 环境变量 .env .env.local # 日志 *.log npm-debug.log* # 编辑器 .idea/ .vscode/ *.swp

确认无误后执行：

git add . git status

git status一定要看一眼，它列出的是"将要被提交的文件列表"。如果发现某个大文件或敏感文件出现在列表里，别急着commit，先把它加进.gitignore，再执行一次git add .。这一步是挡住意外内容进历史的最后一道闸门。

确认列表没问题后，执行第一次提交：

git commit -m "Initial commit: 项目描述"

提交信息不要写"first commit"这种没有信息量的内容。公开仓库的提交历史会被很多人看到，第一行提交信息就是门面，规范示例如：

• feat: 初始化项目结构，添加基础模块
• docs: 新增README说明文档
• chore: 添加.gitignore和许可证配置

4.2 关联远端地址与第一次push

如果用的是入口克隆方式，远端地址已经自动配好了，用下面命令验证：

git remote -v

如果输出里有两个地址（fetch和push），说明关联成功。如果用是入口二手动添加的方式，执行同样的验证。接着就可以push了：

git push -u origin master

这里分支名以实际为准，本地分支名是master就写master，是main就写main。-u参数的作用是把本地分支和远端同名分支建立"上游关联"，也就是告诉Git：以后在这个分支上直接执行git push、git pull，默认操作的就是这个远端分支。只设置一次，之后就能省掉origin 分支名这些参数。

push过程如果走HTTPS，会提示输入用户名和密码/Token；走SSH的话，如果是第一次连接某个域名的Git服务，通常会提示确认指纹（输入yes），之后就不再问了。

4.3 推送完成后的验证步骤

push成功后，终端会显示类似branch 'master' set up to track 'origin/master'和Everything up-to-date的结果。但我不建议看到这个提示就关终端，公开仓库的落地方要做的验证比这多一步。

首先，打开AtomGit的仓库页面，正常情况下应该能看到刚才提交的文件列表，以及最新的commit记录。留意一下文件列表是否完整，README是否有渲染出来，.gitignore里的内容是否没有作为普通文件出现在仓库里。

其次，从"消费者"视角验证一遍——打开浏览器的无痕模式或普通模式（不登录AtomGit账号），直接访问仓库地址。如果能正常看到代码列表和说明，才说明这是真正意义上的"公开仓库"。

最后，在另一个空目录里执行一次克隆测试：

git clone https://atomgit.com/你的用户名/仓库名.git

如果能把仓库完整拉下来，那这条"代码提交至AtomGit平台自建公开仓库"的链路就算真正跑通了。这一步很多人忽略，但它恰恰能在出现问题前发现问题——比如某个大文件导致克隆超时、某些目录误传导致体积异常，clone下来之后什么都清楚了。

5. 推送环节的高频翻车现场：被拒、分支错位与凭据失效

5.1 远端已有初始提交导致的push被拒

这是新手最常遇到的报错场景：本地项目建好之后自行git init并提交了代码，准备推送到一个已经在AtomGit上"初始化过（有README）"的仓库，结果push时看到一段刺眼的红字：

! [rejected] master -> master (fetch first) error: failed to push some refs to 'https://atomgit.com/你的用户名/仓库名.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again.

报错的本质是：远端分支上有一些你本地没有的提交（比如平台生成的README），而Git出于安全考虑，不允许直接覆盖远端历史。解决方式也很明确——先把远端提交拉下来合并，再推送本地提交。

git pull origin master --rebase git push origin master

这里我特意加了--rebase参数。它和--merge的区别在于，rebase会把本地未被推送的提交"重放到"远端最新的提交之上，提交历史是一条直线，干净好读；如果用默认的merge方式，容易产生一个额外的"Merge branch 'master' of ..."合并提交，对公开仓库来说，历史会显得有点乱。

如果远端和本地改的是同一个文件，pull时可能产生冲突。Git会在文件里插入<<<<<<< HEAD、=======、>>>>>>>这样的冲突标记。打开文件，保留想要的版本，删掉冲突标记，然后git add 文件名，再git commit --continue完成合并提交。第一次遇到冲突不用慌，这是Git协作中再正常不过的事，处理过一次之后就明白逻辑了。

5.2 本地分支和远端分支名不一致

文章第2部分提到，AtomGit创建仓库的默认分支可能是master也可能是main。如果本地用git init初始化的仓库默认分支是master，而远端默认分支是main，会出现两类问题。

第一类：本地git push -u origin master时提示找不到对应远端分支，或者推送成功后在AtomGit页面上能看到master分支，但页面默认展示的还是main分支，两份代码处在两个分支上，谁也看不见谁。

解决方式是把本地分支改成和远端一致：

# 查看当前分支名 git branch # 把本地分支改名为main并切换到main分支上 git branch -M main # 重新推送并建立跟踪关系 git push -u origin main

-M的作用是"无论当前分支名是什么，一律强制改名"。这是在GitHub、AtomGit这类以main为默认分支的平台里很常用的操作。

第二类：只设置了git remote add origin，但没指定分支就执行git push origin master，系统提示类似error: src refspec master does not match any。这种情况通常是本地还没有任何提交，或者当前分支名不叫master。解决办法是先确保有提交（git status确认干净），再用git branch看看实际分支名，按上面的方式改名后重推。

5.3 HTTPS凭据失效和反复要求输入密码

如果你选择了HTTPS通道，并且关闭了系统弹窗式的凭据管理，很可能出现每次push都要求输入用户名和密码的情况。频繁输入会让人很烦躁，这里有两个解决方向。

方向一：启用Git自带的凭据缓存/凭据管理器。Windows上安装Git时自带的Git Credential Manager可以在系统弹窗里安全保存凭据，只要配置一次，后续免密推送。macOS上则用osxkeychain。启用方式：

git config --global credential.helper manager

或者macOS：

git config --global credential.helper osxkeychain

如果你用的是平台提供的访问令牌而非账号密码，也一样会被安全存储，下次push时不需要再输入。

方向二：切换成SSH通道。SSH方式从机制上就不存在"凭据有效期"的问题，私钥一直存在本地，只要配置过一次公钥，后面就彻底免密。如果你已经生成了密钥并且配置到AtomGit，把远端地址改一下即可：

git remote set-url origin git@atomgit.com:你的用户名/仓库名.git

然后git remote -v验证一下，后续push就不再触发密码确认了。

两个方向我更推荐方向二，公开仓库的维护是长期行为，SSH一劳永逸；方向一适合偶尔用HTTPS应急的场合。

5.4 误提交敏感信息后的补救思路

这个场景我希望你永远用不上，但公开仓库的发布流程里必须讲，因为一旦发生，影响和普通私有仓库完全不是一个量级。

如果刚发现某条commit里包含密码或密钥文件，而时间很近、仓库还没被太多人看到，最简单的处理是：把这个commit从Git历史里抹掉，或者直接把整个仓库删除重建。公开仓库没有"回滚了别人就看不到"这回事，历史里的内容一旦暴露就是暴露了，不存在安全的撤回。

如果仓库已经被人fork或克隆了，那历史里那条敏感信息就彻底收不回来了。这时候正确的姿势不是继续删除文件，而是立即去相关平台吊销那些密钥、重置密码，同时用BFG Repo-Cleaner或git filter-repo这类工具重写历史，让之后的提交不会带着这个包袱。但这些都属于"亡羊补牢"的动作，最有效的办法仍然是：在git add .之前，用git status检查，用.gitignore挡牢，不给敏感信息进历史的机会。

我在实际使用中自己有个小习惯：第一次push之前，在仓库目录里执行一次grep -rni "password\|secret\|api_key\|token" . --exclude-dir=.git，把明显是密钥的东西扫一遍。然后再commit、再push。多花两分钟，换来的是公开仓库的绝对安全，这笔账怎么算都划算。