企业官网建设流程全解析

代码只在你自己电脑里的时候，一切看起来都挺正常：文件在硬盘上躺着，Git也时不时提交几个版本。可一旦换电脑、加同事、部署服务器，这种"单机工作流"立刻让你寸步难行。这篇东西想把一个最基础的场景完整走通：在Gitee上创建仓库，然后把本地项目推送上去。从注册账号、安装Git，到生成密钥、关联远程、推送代码，每一步按实际操作顺序拆开讲，连同我踩过的坑一起给你。

这篇文章适合刚接触版本托管的新手，也适合用过Git但没在Gitee上完整操作过的人。花十分钟跟着走一遍，你可以得到一套能重复使用的标准流程。以后不管你是推送自己的开源项目，还是把公司的内网仓库搬到Gitee私有仓库，都能直接照抄这套路径。

1. 开工前的准备：账号、工具与基础配置

1.1 注册Gitee账号的细节

Gitee（码云）是国内最大的Git代码托管平台之一，访问速度和中文文档都比国外平台友好得多。注册过程本身没什么难度，但我还是建议你用真实信息完成实名认证——不是强制所有功能都要实名，但创建私有仓库、开启Gitee Pages、给仓库加成员等功能，实名之后会顺畅很多。亲测用昵称注册不实名的账号，有些仓库权限相关的操作会弹验证提醒，反而浪费时间。

注册时尽量绑定常用手机号和邮箱，后面配置Git提交信息时，邮箱最好和Gitee邮箱保持一致。这不算硬性要求，但如果邮箱不一致，你的提交记录在Gitee上会显示成"未关联账号"的灰色头像，看起来就像路人提交的，维护开源项目时不雅观，自己查贡献图也查不到。

1.2 Git安装：不要在这步省时间

Windows用户直接去Git官网下载，安装时一路Next问题也不大，但有三个选项值得留意：

• 默认编辑器建议选Nano，别选Vim。Vim对不熟悉的人简直是灾难，推送时如果需要修改合并信息，卡在Vim界面里进退两难的滋味不好受。
• PATH环境变量选默认的"Git from the command line and also from 3rd-party software"就好，既保证了git命令在CMD和PowerShell里可用，又不干扰其他软件。
• 换行符转换建议选"Checkout as-is, commit as-is"。不少教程推荐选第一个自动转换CRLF，但我在实际项目中经常遇到转换后配置文件被改动、无端出现大量diff的情况。选最后一个最省心。

macOS用户最简单的是先装Homebrew，然后brew install git；Linux用户用发行版自带的包管理器装就行，比如Ubuntu下sudo apt install git。安装完成后，在终端敲git --version，能看到版本号就说明装好了。

1.3 全局配置：提交者的身份卡片

Git每次提交都会记录提交者姓名和邮箱，这是无法跳过的。装了Git之后第一件事就是配置这两个全局参数：

git config --global user.name "你的名字" git config --global user.email "你注册Gitee的邮箱"

用git config --list可以查看所有配置。注意--global表示对当前电脑所有仓库生效，如果你某个特定项目想用不同的身份（比如公司项目用公司邮箱），在项目目录里去掉--global再配置一遍即可。

这里有个小坑：如果你直接用IDE里的Git功能提交，有些IDE会弹窗让你填用户名和邮箱，填完后IDE会把它写到当前仓库级别的config里。这个仓库配置会覆盖全局配置，所以你可能会遇到"我在全局配好了名字，怎么这个仓库显示的还是别人"的情况。排查方法就是看git config --list里user.name在仓库级别和全局级别是否一致。

2. 让本地与Gitee互相信任：SSH密钥配置

2.1 为什么我强烈推荐SSH而不是HTTPS

Gitee支持HTTPS和SSH两种协议访问仓库。HTTPS方式每次推送都要输用户名和密码，虽然可以借助凭据管理器记住，但对需要频繁推送的开发流程来说，既啰嗦又容易中断。更麻烦的是，HTTPS密码输错太多次，Gitee会临时封锁IP或账号，全办公室跟着受害。

SSH方式在配置好密钥之后一劳永逸，推送拉取都不需要输入任何东西，只需要确认公钥被Gitee信任。这里的原理可以打个比方：SSH密钥像一把钥匙和一把锁。你把公钥（锁的备份）交给Gitee服务器，私钥自己保存在本地。推送代码时，Gitee拿着你的公钥来验证你私钥的签名，验证通过就放行。

2.2 生成SSH密钥的全过程

在终端里执行：

ssh-keygen -t rsa -b 4096 -C "你的邮箱"

敲完回车后，它会问你要把密钥文件保存在哪里。默认位置是~/.ssh/id_rsa，直接回车使用默认位置即可。接着让你输密码短语（passphrase），这个可以留空，也可以输一个简单的密码。留空的含义是：只要别人拿到你电脑上的私钥文件，就能完全控制你的代码仓库。如果输密码短语，每次操作都要输入一次密码，安全性和便利性自行权衡，我自己的项目是留空的。

命令执行完之后，~/.ssh目录下会出现两个关键文件：

• id_rsa：私钥文件，绝对不能泄露给任何人，不要上传到任何网盘或代码仓库。
• id_rsa.pub：公钥文件，这是要交给Gitee的内容。

公钥内容可以用以下命令查看并复制：

cat ~/.ssh/id_rsa.pub

Windows用户如果用的是Git Bash，同样支持以上命令。

2.3 把公钥添加到Gitee

登录Gitee网页端，点击头像进入设置，左侧菜单找到"安全设置 → SSH公钥"。把id_rsa.pub文件里的内容完整复制粘贴到"公钥"文本框，标题随便填一个方便识别的名字，比如"我的办公电脑"，然后提交。

Gitee网页上保存的其实是公钥的文本内容。复制时注意不要漏掉最后的邮箱后缀，也不要多复制换行。粘贴完成后，在本地终端验证连接：

ssh -T git@gitee.com

如果配置正确，会返回类似Hi 你的用户名! You've successfully authenticated, but GITEE.COM does not provide shell access.的提示。看到这行字，说明SSH通道已经打通。

2.4 SSH验证失败怎么排查

ssh -T git@gitee.com如果报Permission denied (publickey)，按顺序检查三件事：

• 公钥是否已粘贴到Gitee（打开网页设置确认一下，很多人粘贴时复制成了私钥id_rsa的内容，这完全不行）；
• 本地私钥是否存在且路径正确（ls ~/.ssh看有没有id_rsa）；
• SSH agent是否加载了私钥。Windows下偶尔需要执行ssh-add ~/.ssh/id_rsa让agent重新加载。

一个冷知识：如果你电脑上之前配置过GitHub的SSH密钥，并且把同一个公钥同时添加到GitHub和Gitee，这是完全合法的。公钥本身就是公开信息，在哪个平台添加都无所谓，只要私钥安全就行。

3. 在Gitee上创建仓库：参数选择有讲究

3.1 点击"新建仓库"之前的决策

Gitee左上角"+"号下拉菜单里有"新建仓库"，点击进入创建页面。这个页面上需要填的东西不多，但每一项都影响后面的流程。

• 仓库名称：只能用字母、数字、下划线、中划线和中文字符，不能带空格。建议用小写字母加中划线，比如my-blog、erp-system，这是Git生态约定俗成的风格。
• 路径：仓库名称填写后路径会自动生成，路径是最终克隆地址的一部分，确定之后不建议修改。
• 是否私有：私有仓库只有你自己和被你添加的成员能看到，适合公司项目、尚未完成的个人项目。公开仓库所有访客都能看，适合开源项目。Gitee创建私有仓库不设数量限制，这一点对个人开发者很友好。
• 初始化仓库：Gitee会问你初始化时是否自动创建README文件、.gitignore文件、开源许可证等。

3.2 千万不要勾选"初始化仓库"里的选项

这部分是新手最容易踩的坑。

如果你在Gitee创建仓库时勾选了"初始化仓库"，那么远端仓库就自动产生了一个包含README.md的提交。当你本地项目准备就绪，第一次执行git push时，Git会发现本地和远端的提交记录互相独立，直接拒绝合并推送，报错信息通常是! [rejected] master -> master (fetch first)。

要解决也不难，但会额外增加一个合并步骤。官方推荐的做法是：

git pull origin master --allow-unrelated-histories

这个参数的意思是：允许两个没有共同祖先历史的仓库合并。合并之后可能产生冲突文件，需要手动处理再重新提交。操作不复杂，但纯属浪费时间——明明可以避免的。

所以我的建议非常明确：创建仓库时，所有初始化选项一律不勾选。.gitignore文件完全可以在本地自己写，README文件也可以本地创建后推送，没必要让远端先产生一次提交。干干净净的空仓库，反而让后续操作路径最清晰。

3.3 开源许可证怎么选

创建公开仓库时，Gitee会让你选开源许可证。如果你不打算开源，选"无"就行。如果要开源，选哪个许可证取决于你对衍生作品的态度。MIT最宽松，代码原作者放弃责任，允许别人随意使用甚至闭源商用；Apache 2.0比MIT多一点专利保护条款；GPL要求衍生作品也必须开源。个人项目我建议选MIT，商业公司项目建议咨询法务，别拍脑袋选。

4. 本地项目与远程仓库对接：从0到推上去

4.1 本地初始化为Git仓库

假设你本地有个项目文件夹，里面是你的代码。在项目根目录打开终端，执行：

git init

这一步会在当前目录生成一个隐藏的.git文件夹，里面存放Git的全部版本历史信息。可以用git status查看当前仓库状态，此时所有文件都会显示为未跟踪（untracked）状态。

如果你的项目里有一些不需要进入版本控制的文件，比如日志、缓存、编译产物、本地配置、IDE配置文件等，先把 .gitignore 文件创建好再执行 add。这里分享一个实用的最小化 .gitignore：

# 依赖目录 node_modules/ target/ vendor/ # 编译与缓存 *.pyc *.class .DS_Store *.log # IDE配置 .idea/ .vscode/ *.iml # 本地环境配置 .env.local config.local.php

我见过不止一次同事把node_modules整个提交到仓库，结果仓库体积爆炸、克隆奇慢无比。提前写好 .gitignore，从第一步就避免这种悲剧。

4.2 添加和提交代码

git add . git commit -m "项目初始化：完成基础框架搭建"

git add .会把当前目录下所有未被 .gitignore 排除的文件加入暂存区。git commit会把这些文件以快照形式保存到本地版本库。

提交信息规范上，我推荐用 gitmoji 风格或者 conventional commits 风格，比如feat: 新增用户登录功能、fix: 修复订单金额计算错误。这种方式不仅人看着清楚，一些自动化的代码审查工具也能识别。实在想不出怎么写，至少别写update这种毫无信息量的提交信息。

这里有个新手最容易困惑的点：commit只发生在本地，不会影响远程仓库。你以为提交了代码别人就能看到，其实还差得远。

4.3 关联远程仓库

回到Gitee刚才创建好的空仓库页面，页面上会显示仓库地址。在Gitee上，克隆地址有两种格式：

• HTTPS格式：https://gitee.com/用户名/仓库名.git
• SSH格式：git@gitee.com:用户名/仓库名.git

因为我们前面配置了SSH密钥，所以选择SSH格式。在本地终端执行：

git remote add origin git@gitee.com:用户名/仓库名.git

这里的origin是远程仓库的默认名称，相当于给这个地址起了一个别名。如果你想添加多个远程仓库（比如同时推到Gitee和GitLab），可以用不同的名字，比如：

git remote add gitee git@gitee.com:用户名/仓库名.git git remote add gitlab git@gitlab.com:用户名/仓库名.git

查看当前仓库关联了哪些远程仓库：

git remote -v

如果发现关联错了，可以删除重新关联：

git remote remove origin

4.4 推送代码到Gitee

关联好远程仓库后，终于到了推送这一步：

git push -u origin master

拆解一下这条命令：

• git push：把本地提交推送到远程。
• origin：推送的目标远程仓库，也就是刚才添加的那个别名。
• master：本地分支名。如果本地当前分支不是master，这条命令会报错，后面讲。
• -u：这个参数是--set-upstream的简写，意思是把本地master分支和远程master分支建立追踪关系。执行过一次之后，以后直接git push就能推送到对应分支，不用再带参数。

执行过程中如果遇到SSH密钥验证提示（第一次连接可能会出现），输入yes确认。看到类似Counting objects、Writing objects的输出，最后返回To git@gitee.com:用户名/仓库名.git和分支信息，就说明推送成功了。去Gitee页面刷新，代码已经出现在仓库里。

5. 日常使用中的完整工作流与进阶操作

5.1 一套顺手的日常提交推送流程

推送成功一次只是开始，后面日常开发中你会反复用到这套流程：

git status # 查看工作区状态 git add . # 暂存改动 git commit -m "feat: 新增接口文档" # 提交到本地 git pull origin master # 拉取远程最新代码并合并（如果多人协作） git push origin master # 推送本地提交到远程

很多人在小团队里会跳过pull直接push，这个习惯很危险。如果同事在你拉取代码之后提交了新版本，你的push会被拒绝，报错! [rejected] master -> master (non-fast-forward)。正确处理方式是先pull合并，解决冲突后再push。

当然如果你是自己一个人开发，通常是本地提交满意了再推，不用每次push前都pull。

5.2 从Gitee拉取已有项目

换个场景：项目已经在Gitee仓库里了，你换了台电脑，要把项目拿到本地。这时候不需要init，直接克隆：

git clone git@gitee.com:用户名/仓库名.git

克隆会自动完成初始化仓库、关联远程、拉取所有提交记录和文件。如果仓库比较大，可以加上--depth=1只拉取最近一次提交，可以大幅加速，但这种浅克隆在后续push操作时会有一些限制，只在临时查看代码时用。

如果已经在本地开发但没有关联远程，而代码内容正好和已有仓库内容一致，更推荐的做法是把已有仓库克隆到新目录，把自己改动的文件复制进去，而不是强行合并两个独立的Git历史。强合容易把提交历史搞乱，提交图变得没法看。

5.3 分支管理：一个简单但重要的习惯

现在Gitee和GitHub在新仓库上的默认分支名都在向main转变，不少人在本地执行git init后默认分支是master，推送时就会出现两边分支名对不上的情况。

我在之前的项目中踩过一次：本地仓库初始化的默认分支是master，Gitee新仓库的默认分支却是main，推送时直接报错error: src refspec master does not match any.。解决方案有两种：

git branch -M main # 把本地master分支重命名为main git push -u origin main

或者强行指定推送目标分支名：

git push origin HEAD:master

我倾向第一种，重命名后保持本地和远端分支名一致，避免后面每次push都要带参数。团队协作时，约定统一的分支名比什么都重要。

5.4 用 .gitignore 挡住不该上传的文件

.gitignore 的实际效果是：被它忽略的文件在git status里不会出现，也不会被git add .暂存。所以如果你之前已经误提交了某些文件，光改 .gitignore 是没有用的，必须把文件从Git追踪中移除：

git rm -r --cached node_modules/ git commit -m "chore: 移除误提交的依赖目录"

--cached参数只会从Git索引中移除文件，不会删除磁盘上的实际文件，放心操作。

6. 常见问题与排查方法

6.1 换个地方继续干

Q：推送时提示fatal: not a git repository？

A：当前目录不是Git仓库。在项目根目录执行git init，或者如果你本来应该克隆/clone却直接复制了文件，先git init再git remote add origin 地址。

Q：Permission denied (publickey)？

A：SSH密钥验证失败。检查顺序：公钥是否上传到Gitee→私钥文件是否存在→ssh-agent是否加载了私钥→Gitee页面上粘贴的是不是id_rsa.pub的内容（不是id_rsa）。

Q：push时报! [rejected] master -> master (fetch first)？

A：远程仓库有本地没有的提交。先执行git pull origin master --allow-unrelated-histories（如果是第一次关联），或直接执行git pull origin master（已有共同历史），处理冲突后再push。

Q：push时报error: src refspec master does not match any？

A：本地没有master分支。可能本地分支叫main，先git branch -M main或者用git push origin HEAD:master。

Q：每次都要求输入用户名和密码？

A：你使用的是HTTPS地址，而不是SSH地址。执行git remote set-url origin git@gitee.com:用户名/仓库名.git切换。

6.2 改错提交信息怎么办

如果你刚提交完，发现提交信息写错了，还没推送远程，直接改：

git commit --amend -m "feat: 修正后的提交信息"

--amend的原理是重建最后一次提交，把新信息替换旧信息。注意它只会修改最近一次提交，如果想改之前的提交，那就得用git rebase -i，复杂度上升一个档次，新手不建议轻易尝试。

如果错误提交已经推送到远程且别人已经拉取了，千万别用amend重写历史，会让协作者进入噩梦状态。宁可老老实实再补一个提交，也不要在已公开的历史上做文章。

6.3 换行符导致的diff混乱

项目中不同操作系统协同工作时，Windows的CRLF和Linux的macOS的LF换行符差异会产生大量无用diff。如果你选择的换行符策略不正确，可能push之后所有人拉下来代码都会提示整个文件被改动。

我的解决方案是三种：

• 仓库根目录添加.gitattributes文件，声明部分文件的换行符策略；
• 团队成员在各自Git配置里统一设置git config core.autocrlf true（Windows）或false（Linux/macOS）；
• 最重要的，不要把不同编辑器保存的不同换行符混在一起提交。提交前用编辑器的"统一换行符"功能处理一遍。

6.4 大型文件推送失败

如果项目里有超过100MB的二进制文件（比如打包好的安装包、数据集），Gitee会直接拒收。解决方案：

• 如果是构建产物，加入.gitignore，让使用者自己构建；
• 如果是必须共享的大文件，用Git LFS（Large File Storage）管理，Gitee对LFS有限额支持，个人项目够用；
• 如果已经误推了，用git filter-repo或BFG工具清理历史，不过这类重写历史的操作务必谨慎。

7. 个人使用中的一些建议与体会

我在这个流程上折腾过多次之后，总结出一条实践心得：推送代码之前，先想清楚仓库定位。如果是个人备份项目，私有仓库加合理的提交信息就够了；如果是开源项目，README写清楚项目简介、安装方式、运行截图，这些在开源初期比代码本身更能吸引人。

项目管理层面，我还建议你定期push，不要积攒一堆commit才推一次。一方面降低本地硬盘损坏丢失代码的风险，另一方面提交记录保持连贯，万一某个节点出问题，定位起来容易得多。

Gitee Pages是个免费又好用的静态网站托管服务，如果你仓库里是一个前端项目或纯静态页面，推上去之后可以在仓库设置里直接开启Pages，一个线上地址就有了，连服务器都不用买。我第一次尝试时，配置完等一两分钟再访问，还是挺顺畅的。如果你手头有闲置的静态资源，去设置里瞄一眼没坏处。