企业官网建设流程全解析

1. 强推之前，先搞清楚Git在怕什么：远程空仓库与本地历史的第一次握手

很多人第一次接触"推送本地新建项目到Gitee或GitHub"时，都会遇到一个极其常见的报错：failed to push some refs，或者是Updates were rejected because the remote contains work that you do not have locally。然后网上搜教程，回复千奇百怪，有说删了重建的，有说强推的，有说拉下来合并的，新手一脸懵。

我结合Git、Gitee、GitHub的使用场景，把这个问题掰开揉碎了讲透。先说结论：新建的远程仓库在没有任何初始化文件时，它是一条真正干净的空白历史线；你的本地项目是一条完全独立的历史线。两条线第一次握手，用强制推送是最省事、最安全的做法。

1.1 为什么新建的远程仓库会"拒绝"你的推送

要理解这个拒绝，先要理解Git是怎么存储和比较历史的。

Git世界里，每一次commit都会生成一个SHA-1哈希值，并且这个哈希值会带上"父提交"的哈希值。换句话说，每一次提交都相当于链表里的一个节点，整个提交历史是一条有向无环图。你本地有commit，远程仓库也有commit，这两条链是否"相关"，取决于它们是否有共同的祖先节点。

如果你在Gitee上新建仓库时，没有勾选"初始化仓库"之类的选项，那么远程仓库就是一个完全空白的仓库——它没有任何commit，甚至没有分支。此时你执行git push，本质上是告诉远程："我这里有完整的一条历史线，请把你那条空白历史线的指针，指向我这边的顶端节点。"

这个操作在Git的设计里是被允许的。但问题在于，很多平台新用户在创建仓库时，会顺手勾选“自动生成README文件”“自动生成.gitignore”“自动生成开源许可证”。只要勾了任何一个，远程仓库就立刻有了一个或多个commit，它的历史线不再是空白，而是有一个独立的起点。

到了这一步，你本地的历史和远程的历史就是两棵完全不相干的树。Git在没有共同祖先的情况下，默认拒绝直接推送，因为它不知道该以哪条线为准，强行合并可能会造成无法预测的结果。于是你收到了failed to push some refs。英文提示里往往还写着maybe you want to integrate the remote changes first（也许你应该先合并远程的改动）。很多新手看到这句话就跑去执行git pull，结果又遇到refusing to merge unrelated histories（拒绝合并无关的历史）——这就是第二个坑。

1.2 强制推送到底做了什么

git push -f，也就是强制推送，对应的长参数是--force。它的原理非常简单：放弃远程仓库分支指针当前所指的commit，直接把它推到本地分支的最新commit处。

换句话说，强制推送不是在"合并"两条历史线，而是在"覆盖"。对一个新的、刚刚创建、除了平台自动生成的README或.gitignore之外什么都没有的仓库来说，远程上那些自动生成的commit没有任何保留价值。强制推送一执行，远程分支指针就直接指向你本地的历史线，之前那些平台生成物相当于被从历史里摘除。

这是不是意味着强制推送很危险？分情况。如果你是在一个多人协作的成熟仓库上执行git push -f，那危险是致命的——你等于把远程团队共同的历史改写成了你本地的那一条，别人的提交可能瞬间"消失"。哪怕能用git reflog找回，代价也非常高。但这里有个前提我们已经反复强调：**这个仓库是你刚刚新建的、还没有人提交过有价值内容的仓库。**在这个场景下，远程仓库里没有任何值得保留的东西，强推的成本为零，收益是省掉了处理"无关历史"合并的所有麻烦。

1.3 为什么只有"第一次"才建议强力推送

这个问题要看透两层：一是远程仓库当前状态的确定性，二是Git合并不相关历史的成本。

• 第一次推送时，远程仓库要么是完全空白，要么只有平台自动生成的几个初始化文件。无论哪种，远程的内容都是"可再生且无价值"的。此时使用强推，心理负担可以完全放下。
• 第二次及以后，本地项目和远程仓库已经建立了同一个祖先历史。此时你只需要正常git push，Git能自动算出本地领先远程多少个commit、远程领先本地多少个commit，执行的是一个干净的快速前进（fast-forward）或合并推送。这个阶段如果还使用强制推送，就会抹掉远程上其他人的提交，等于亲手制造事故。

所以，"建议第一次强制推送"的真正含义是：在远程仓库还没有形成真正价值之前，用最干脆的方式确立一个干净的共同起点。一旦起点确立，之后的每一次push都应回归常规流程。

2. 仓库初始化时那两个勾选框，关掉才是正确操作

Gitee和GitHub在创建新仓库时，都会遇到一个选择页面：要不要初始化README、要不要生成.gitignore、要不要添加许可证。有些新手觉得"平台既然提供了就勾上，省得自己写"，实际上这是一个需要谨慎对待的决定。

2.1 自动生成的.gitignore真不如自己写

平台提供的.gitignore模板，是根据你选择的语言和框架自动生成的。听上去很方便，实际用起来问题很多。

第一，模板里的规则往往过于笼统。以Java多模块项目为例，平台生成的模板可能只包含target/、*.class这些基础项，但你的项目可能还有本地配置目录、IDE目录、启动日志目录。这些没被.gitignore覆盖的文件，一旦被误git add提交进仓库，后面清理起来比一开始写规则要麻烦得多。

第二，模板是"别人给的"，不是"你验证过的"。我在实际项目里遇到过不止一次，依赖平台模板生成的.gitignore，把某些关键目录忽略掉了，导致别人拉取代码后编译缺少必要文件。这类问题排查起来非常隐蔽。

第三，不同平台、不同语言的模板质量参差不齐。与其依赖平台生成，不如自己在本地项目里写一份只属于这个项目的.gitignore。你会发现，写规则的过程，也是梳理项目结构的过程。

2.2 LICENSE不是随便选的

开源许可证（LICENSE）是一个有法律意义的内容，不是随手选一个就行的。

平台给你的选项包括MIT、Apache 2.0、GPL-3.0、BSD、LGPL等。每种许可证对使用者的约束完全不同。举个典型例子：MIT许可证非常宽松，允许别人自由使用、修改、分发你的代码，甚至可以闭源商用；而GPL-3.0带有强传染性，只要用了你的代码，对方整个项目都大概率需要以GPL方式开源。

对于一个刚起步的本地项目，你可能还没想清楚这个项目要不要开源、要不要商用、别人能不能随便抄。这时候让平台自动生成一个LICENSE，相当于在一张空白合同上随手签了名。我个人的建议是：新建仓库时什么都不勾选，等项目的定位、授权模式想清楚了，再手动添加LICENSE文件。

2.3 如果已经勾选了自动生成文件，怎么补救

如果你创建的仓库已经勾了READEME或.gitignore，别慌。因为是新建仓库，补救成本非常低，只有两种处理方式。

方式一：丢弃远程初始化文件，本地直接覆盖

如果远程仓库只是在创建时自动生成了README.md、.gitignore或LICENSE，仓库里没有任何其他人提交的内容，那你直接忽略它就好。本地完成git commit之后，执行：

git push -u origin main --force

强推会让远程分支指针直接指向你本地的历史，之前自动生成的那些文件不再成为远程主线的组成部分。操作前记得确认一下远程仓库是否有"别人提交的内容"，这一步很重要。如果这是你一个人刚建的仓库，放心干。

方式二：拉取远程初始化文件并合并

如果你想保留平台自动生成的README等内容（比如想让仓库展示页有个介绍），那可以用合并方式处理。先拉取远程历史，并显式允许无关历史合并：

git pull origin main --allow-unrelated-histories

这一步会把远程自动生成的README.md等文件，和你的本地文件合并到一个工作区里。如果两边都创建了同名文件（比如你都写了一个README.md），Git会停下来让你手动解决冲突。处理完冲突后git add . && git commit -m "merge remote init"，再正常git push即可。

比较两种方式，我几乎总是推荐第一种。原因简单纯粹：新建仓库的自动化初始文件，不值得你为它们做一次合并操作。

3. 从零到一：本地新项目推送Gitee/GitHub的完整步骤

这一节把完整的流程走一遍。无论你用的是GitHub还是Gitee，步骤都是一样的，只是仓库地址的域名不同。这里我以Gitee为例，GitHub用户把域名换成github.com即可。

3.1 基础环境：安装Git与全局配置

• Windows：直接下载Git官方安装包。安装时会询问调整PATH的方式，建议选择"Git from the command line and also from 3rd-party software"，这样在cmd、PowerShell里都能用。其余选项保持默认即可。
• macOS：如果装了Homebrew，执行brew install git。没有Homebrew的，可以直接下载官方安装包。
• Linux（Debian/Ubuntu系）：sudo apt update && sudo apt install git。CentOS系列用sudo yum install git。

安装完成后，先做全局身份配置。这一项如果不做，Git会直接拒绝commit，或者用一串莫名其妙的名字记录提交。

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

为什么要配成全局？因为Git每次提交时都要记录作者和提交者信息。不配置，后续提交会失败，报错Please tell me who you are。全局配置的好处是：只要不特意指定，这台机器上所有仓库的默认提交身份都是你。

3.2 SSH密钥的生成与平台绑定

推送代码有HTTPS和SSH两种通道。HTTPS需要每次输入账密（或者配置token），SSH在绑定密钥后可以实现免密推送。我建议直接用SSH，稳定而且省事。

先检查本机是否已经有SSH密钥：

ls -al ~/.ssh

如果看到id_ed25519.pub或者id_rsa.pub这类文件，说明你已经生成过密钥。如果没有，执行生成命令：

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

这里推荐Ed25519算法，比RSA更安全，生成的密钥也更短。命令执行后会问你保存位置和口令，直接一路回车即可，生成的默认位置是~/.ssh/id_ed25519。接下来查看公钥内容：

cat ~/.ssh/id_ed25519.pub

复制这段公钥，登录Gitee后进入：设置->安全设置->SSH公钥，粘贴并保存。GitHub上的入口是Settings->SSH and GPG keys->New SSH key。测试一下是否绑定成功：

ssh -T git@gitee.com

如果是GitHub，则是：

ssh -T git@github.com

首次连接会提示确认指纹，输入yes回车即可。看到欢迎信息，说明密钥绑定成功，可以走后续流程了。

3.3 新建仓库：关键的选项不要选

在Gitee或GitHub上点击"新建仓库"，填写仓库名称、描述，选择公开或私有。注意：仓库初始化选项那一栏，README、.gitignore、License全部不要勾选。这也是本文最核心的一条操作建议。让远程仓库保持一个真正的空状态，后续推送会干净利落。

创建完成后，你会得到一个远程仓库地址，形如：

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

记下来，下一步要用。

3.4 本地项目初始化与首次推送

进入你的本地项目根目录。这里我把项目目录假设为~/my-project。

cd ~/my-project git init

执行git init之后，项目目录里出现一个隐藏的.git文件夹，这就是Git的本地版本库。接着添加所有文件到暂存区：

git add .

然后提交。提交信息建议写清楚，第一次可以写init project，实在不知道写什么的，写first commit也比空白强。

git commit -m "init project"

接下来关联远程仓库。远程仓库的默认名字习惯叫origin：

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

关联完成后，需要确认本地分支名称。Git在不同版本、不同机器上的初始分支名不同，有的叫master，有的叫main。现在Gitee新建仓库的默认分支通常是master，GitHub是main。为了对齐远程，可以在推送前把本地分支改名：

git branch -M master

如果你用的平台默认分支是main，就把命令里的master换成main。执行git branch -M的作用是：如果分支名不对就改名，如果正确就跳过。

最后，执行第一次推送：

git push -u origin master --force

参数拆开讲：

• -u是--set-upstream的缩写，把本地分支和远程分支关联起来。之后你在这个分支上直接git push，不用再写远程分支名。
• --force是强制推送。前面说过，第一次推送用强推可以完全跳过"不相干历史"的处理。
• origin master表示推送到origin远程的master分支。

命令跑完，刷新Gitee或GitHub仓库页面，本地代码应该已经全部出现在远程仓库里了。到了这一步，本地与远程的"第一次握手"就完成了。

3.5 验证推送结果

推送完成后，验证是必要动作。观察三点：

• 远程仓库页面是否出现了你的项目文件；
• 提交历史里的作者是否是你配置的user.name和user.email；
• 分支是否已经变成你本地的分支名，并且是默认分支。

也可以在本机执行git log --oneline查看提交记录。如果远程页面显示的项目文件与你本地一致，说明推送成功。

4. 第一次握手之后：日常推送、代码忽略与排错实战

第一次推送完成后，这个项目就算从"新建推送"阶段进入了"日常维护"阶段。很多人在这一步后又开始踩新的坑，我把高频问题集中讲一遍。

4.1 第二次推送开始，别再用强制推送

第一次推送确立共同历史后，日常提交与推送的流程是这样的：

git add . git commit -m "写清楚这次改了什么" git push

因为用了-u关联过上游，所以直接git push即可。如果这一阶段你习惯每次都加--force，我强烈建议改掉。一旦某次你本地落后于远程且有其他人提交了新内容，强推会把别人的提交覆盖掉，造成的后果比代码冲突严重得多。

如果你在一个分支上写完代码，要合并到主分支，常规做法是：

git checkout main git pull origin main git merge feature-login git push origin main

这里特别强调一点：git pull之前先看一下git status，确认本地没有未提交的改动。否则一旦合并出现冲突，你需要在半成品代码里解冲突，处理起来非常痛苦。

4.2 .gitignore的两种正确打开方式与"修改生效"

新建项目时建议自己写.gitignore。创建文件的方式很简单：

touch .gitignore

或者用编辑器直接新建。文件放到项目根目录，提交到版本库里。规则写法也不复杂，玩明白常用的就够：

• 忽略单文件：直接写文件名，比如.DS_Store
• 忽略目录：目录名加斜杠，比如target/、node_modules/
• 忽略通配：*.log表示忽略所有.log后缀的文件
• 取反：!important.log表示在忽略的基础上恢复这个文件（但是注意取反规则不作用于已忽略目录内的文件，细节较多，不展开）

很多新手的困惑在于：改了.gitignore之后，发现某些文件还是会被提交，或者已经提交的文件没有被忽略。这其实是一个很关键的认知问题。.gitignore只对"未被Git跟踪"（untracked）的文件生效。如果某个文件已经在版本库里被跟踪了，哪怕你事后把它写进.gitignore，Git也不会自动停止跟踪它。

正确的处理方式是先把它从Git索引中移除，再重新添加：

git rm -r --cached . git add . git commit -m "refresh gitignore" git push

--cached参数表示只从暂存区/索引中移除文件，不会动你磁盘上的实际文件。执行这两步之后，那些原本已跟踪的、现在被.gitignore覆盖的文件，就真正被忽略了。

4.3 只有一个SSH密钥，为什么Ping不通平台

先看一个非常典型的报错：

git@gitee.com: Permission denied (publickey).

排查链路按下面这个顺序走，基本能解决九成问题。

1. 先确认密钥是否存在：ls -al ~/.ssh，没有id_ed25519.pub就重新生成并绑定平台。
2. 再确认是否绑定到正确的平台：很多人把公钥绑到了GitHub，却往Gitee推代码，平台当然不认。用ssh -T git@gitee.com可以快速验证。
3. 确认公钥粘贴无遗漏：复制公钥时，注意连结尾的邮箱或者注释一并复制，不能少字符。粘贴后提交保存。
4. 确认用对仓库地址：SSH地址应该是git@gitee.com:用户名/仓库名.git，而不是https://gitee.com/...。如果git remote -v显示的远程地址是HTTPS开头，说明关联错了，用git remote set-url origin改回来。

4.4 修改最近一次提交：git commit --amend的正确用法

有些时候，上一条git commit的消息写错了，或者漏加了文件。如果这个提交还没推送到远程，用git commit --amend非常合适。

git add 漏掉的文件 git commit --amend

会打开编辑器让你修改提交信息。或者你只想改信息：

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

这里要特别注意：如果该提交已经推送到远程，并且这个仓库有其他人也在用，不要对这条提交执行--amend。因为amend本质上是创建了一个新的commit来替代旧commit，提交哈希会变化，远程分支和本地分支的对应关系会被破坏，后续一推送就会出现非快速前进的冲突，又要被迫走一遍强推流程。

4.5 另一种"无关历史"场景：本地拉取远程仓库

除了首次推送，还有一种常见的"无关历史"场景：你在Gitee上有一个已经初始化过的仓库（比如勾选了README），但你想把代码拉到一个全新的本地目录里开发，而不是反推上去。这种情况直接：

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

git clone会完整地把远程历史拉下来并自动建立本地分支，不存在无关历史问题。如果你看到一个老项目让你处理"两个完全无关的历史"时，git pull --allow-unrelated-histories才派得上用场，比如你想把两个独立初始化的项目合并成一个。这个参数的作用是告诉Git："我明确知道这两条历史不相干，你帮我强行合并一次。"但合并完后两个项目的文件可能交错在一起，连根目录结构都需要人工调整，不是清理表面冲突就完事的。

5. 写在最后的几条真实经验

分享几个我自己反复用到的习惯，希望能节省你后面踩坑的时间。

第一，创建仓库时，永远选择不初始化任何文件。每勾选一个选项，远程就会多一个commit，后续处理就多一分麻烦。README也好、LICENSE也好，全部等本地代码推上去之后，再以文件的形式补加到仓库里，再推送一次。这样远程历史干净，Git也不会莫名其妙给你生成冲突。

第二，第一次强推，但只限第一次。我这个习惯一开始源于偷懒，后来发现它是对的：刚创建的空远程仓库没有有价值的commit，force push只是把分支指针从"无"变成"你的提交顶端"，没有任何信息损失。反而是那些"先初始化再手动合并"的做法，浪费时间且容易在解冲突时误删文件。

第三，写.gitignore的时间点，最好定在项目刚初始化时。很多项目到后面才补.gitignore，结果发现target/、node_modules/这些乱七八糟的目录已经被提交到仓库里，历史里的每个commit都带着它们，仓库体积越来越大。虽然可以用git rm -r --cached清理，但历史里残留的内容仍然在。所以，项目初始化那一刻就把.gitignore建好，是最划算的投资。

第四，推送报错时，先读英文原文再动手。Git的报错信息虽然啰嗦，但每一个都带着明确的意图，比如Updates were rejected because the remote contains work that you do not have locally就是在告诉你：远程有你的本地没有的提交。这时候你该做的不是盲目强推，而是先看远程多了什么、有没有你需要保留的东西。等你把Git报错信息读顺了，你会发现自己处理Git问题的速度比搜索引擎快得多。