看到标题里的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-filterD --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地址形如gitatomgit.com:你的用户名/仓库名.git默认分支名master或main这三个信息等会儿本地配置都要用到。2.3 平台初始化模板的隐藏价值平台上勾选自动创建README、自动生成.gitignore看起来像是新手才会用的功能很多老人会建议你全部取消然后本地推一个干净仓库上去。但我实际上更建议第一次就勾上原因有三第一README和.gitignore由平台生成可以确保远端仓库有一个最小的完整结构。本地如果还是一片空白克隆下来直接开干就行不用对着空仓库发呆。第二平台生成的.gitignore模板基于常见技术栈覆盖了主流语言的忽略规则。比如你选了Python它会自动忽略__pycache__/、*.pyc、venv/、.env等比自己从零写要省事。第三平台生成的初始提交会建立一个远端主干本地push时只要在这个主干上追加提交即可不容易出现两个完全无关的历史合并这种处理起来比较麻烦的情况。如果你的需求很明确本地已经有完整项目了那也可以不勾选这些模板直接把本地仓库推到一个空仓库里。两种路径都能走通但作为Day2的教程我推荐采用平台先生成骨架的方式因为后续遇到冲突的概率更低。3. 本地Git环境准备安装、身份配置和远程通道选择3.1 Git安装的三平台对照这一步大多数人在Day1已经做完了如果你还没装这里给一个可直接照做的对照表。操作系统推荐方式说明Windows从git-scm.com下载安装包安装过程中基本都是默认项唯一建议调整的是行尾转换见3.2macOS执行brew install git或安装Xcode Command Line ToolsHomebrew方式版本较新Xcode方式胜在零额外安装Ubuntu/Debian执行sudo apt update sudo apt install git -y官方源的版本可能不是最新但足够日常使用CentOS/RHEL执行sudo yum install git -y如果系统较老可能需要先yum install epel-release装完之后在一个终端里执行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 statusgit 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或者macOSgit config --global credential.helper osxkeychain如果你用的是平台提供的访问令牌而非账号密码也一样会被安全存储下次push时不需要再输入。方向二切换成SSH通道。SSH方式从机制上就不存在凭据有效期的问题私钥一直存在本地只要配置过一次公钥后面就彻底免密。如果你已经生成了密钥并且配置到AtomGit把远端地址改一下即可git remote set-url origin gitatomgit.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。多花两分钟换来的是公开仓库的绝对安全这笔账怎么算都划算。