企业官网建设流程全解析

很多人学全栈开发，都是从"写代码"开始的，写完了本地能跑就觉得自己会了。但真到了要把项目交付出去、拉同事一起协作、甚至触发自动化部署上线的时候，很多人会卡在同一个地方：本地项目怎么上传到Git仓库？Git这个贯穿"开发到上线"全过程的工具，恰恰是新手最容易被忽略、也最该优先补齐的一环。这篇教程我会从Git安装、环境配置、本地仓库初始化、绑定远程仓库（Gitee/GitHub）、日常提交与分支合并，到常见报错的排查思路，一次性讲清楚，目标是让你看完就能完整走通一遍从零到仓库的流程，并且理解每一步背后的逻辑。

1. 为什么上传本地项目是"开发到上线"的第一道关卡

1.1 全栈开发视角下的Git不只是"网盘"

如果你只是一个人写项目，可能觉得Git就是个高级备份工具，代码丢不了就行。但站在全栈开发、尤其是从开发到上线的完整链路来看，Git是整条流水线的源头。

我简单梳理一个典型场景：你在本地开发了一个带前端页面、后端接口和数据库脚本的全栈项目，要上线到服务器。上线过程通常不是手动把文件拖到服务器，而是服务器上的部署脚本去远程仓库拉取最新代码，然后自动构建、重启服务。也就是说，如果代码没有进入仓库，部署流水线根本无从触发。另一方面，团队协作时，每个人从仓库克隆代码、在自己分支上开发、再合并回主干，这个流程完全依赖于仓库里的代码是完整且可用的。我见过不少新手把本地项目压缩包发给同事，结果版本混乱、互相覆盖，最后谁也说不清哪份是最新的——这种痛苦，用Git从一开始就能避免。

所以说，"本地项目上传到仓库"不是开发完成后的收尾动作，而是整个工程化流程的第一道关卡。把这一步走通，后面的分支管理、代码评审、自动化部署才有地基。

1.2 这篇文章的适用对象与阅读建议

这篇教程适合下面几类人：

• 刚入门全栈开发、本地写过几个完整项目、但还没系统用过Git的人。
• 用过git add .和git commit，但不知道为什么有时候推送会报错、怎么解决的人。
• 马上要开始团队项目或实习工作，需要用Git和同事协作的新人。

阅读建议：不要只看命令，重点看每步操作的"为什么"。比如为什么要配置用户名邮箱、为什么要用SSH而不是每次都输密码、为什么.gitignore要尽早写好。这些理解到位了，出问题时你才能自己排查，而不是只会复制网上的命令。文中的所有操作我会以Gitee作为远程仓库示例，GitHub的流程几乎一致，区别只在平台界面细节。

2. 环境准备：先装好Git，并完成三件最重要的初始配置

2.1 各平台安装Git的方法与验证

先把Git装上。不同系统的安装方式有差异，我分别说一下我实测过的做法。

Windows
去Git官网下载安装包，一路Next即可。注意安装过程中有个选择"默认编辑器"的页面，默认用Vim，如果你不熟悉Vim操作，建议改成VS Code或者Notepad++，否则以后写commit信息时可能不知道怎么保存退出。装完后在开始菜单里找到"Git Bash"，这是一个模拟Linux命令行的终端，后续命令建议都在Git Bash里执行，兼容性最好。

macOS
最省事的是通过Homebrew安装：

brew install git

没有Homebrew的话，也可以直接下载安装包，但后续更新麻烦一些。macOS自带的Git版本可能较旧，建议还是用brew装新版。

Linux（Ubuntu/Debian系）

sudo apt update sudo apt install git

装完之后，打开终端验证版本：

git --version

能看到类似git version 2.39.2的输出，说明安装成功。如果提示找不到命令，多半是安装没完成或者环境变量没刷新，重新装一次、重启终端即可。

2.2 用户名、邮箱与换行符配置：这是很多人埋下的第一个坑

安装完先别急着建仓库，有三个全局配置必须做。

第一，设置用户名和邮箱。

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

注意，这里填的用户名和邮箱会记录在每一次commit里，远程仓库平台（Gitee/GitHub）也会用它来关联提交记录。很多新手随便填了一串字符，导致提交历史里显示的是一堆乱码，团队协作时根本没法定位是谁改的。建议用户名用拼音或英文，邮箱用你注册Gitee/GitHub的邮箱，保持一致。

第二，配置换行符处理。

git config --global core.autocrlf true # Windows用户 git config --global core.autocrlf input # macOS/Linux用户

这个配置很容易被忽略，但坑很深。Windows和Linux/macOS的换行符不一样，Windows是CRLF，Linux/macOS是LF。如果不做处理，同一个文件在跨平台协作时会被Git认为"整个文件都变了"，diff一片红，特别影响review代码。Windows下设为true，提交时Git会自动把CRLF转成LF存储；macOS/Linux设为input，提交时把CRLF转成LF，到本地再保留原样。团队里Windows和macOS混用的项目，一定要统一这个配置，否则换行符问题会反复出现。

第三，设置默认分支名。

git config --global init.defaultBranch main

早期Git默认分支叫master，现在很多平台默认用main。提前设置成main，后面初始化仓库和推送时，分支名一致，少一些不必要的手动处理。

这三个配置做完，可以用git config --list查看确认。记住，这些是全局配置，作用于你机器上的所有仓库，一次配置长期有效。

3. 本地仓库初始化：动手之前先想清楚这三件事

3.1 别在错误的目录里执行git init

配置完成，终于要进入正题了。很多人的第一步就是对着项目文件夹敲git init，我建议先停下来，确认三件事。

第一，确认你当前所在的目录确实是项目根目录。比如你的项目是一个my-shop文件夹，里面包含src、public、server、database等子目录，那么你必须在my-shop目录下执行git init，而不是在某个子目录里。如果在子目录里初始化，那么子目录之外的文件就不会被纳管，后面推送上去的仓库就是残缺的。

用pwd查看当前路径，确认无误再执行：

git init

执行成功后，项目目录下会多出一个隐藏的.git文件夹，Git的所有版本信息都存在这里。注意，这个文件夹不要手动修改或删除，删了就等于删掉了整个历史记录。

第二，确认这个目录是否已经是一个Git仓库。有时你从网上下载的项目模板自带.git目录，或者你之前已经初始化过了，再执行git init不会报错，但可能让仓库关联变得混乱。用git status查看一下状态，如果提示Not a git repository，说明确实还没初始化，可以放心执行。

第三，想清楚你不需要把哪些文件纳入Git。这一步也就是.gitignore的编写，我单独拿出来讲。

3.2 .gitignore是仓库健康的第一道防线

很多全栈项目里有一堆不需要、也不应该提交的文件。比如：

• 依赖目录：node_modules/、vendor/、target/（Java的Maven构建目录）
• 环境配置与密钥：.env、application-local.yml、*.pem
• 构建产物：dist/、build/、out/
• IDE配置文件：.idea/、.vscode/、*.iml
• 系统文件：.DS_Store、Thumbs.db
• 日志文件和临时文件：*.log、*.tmp

方法很简单，在项目根目录新建一个文件，命名为.gitignore，把不需要的文件或目录按规则写进去，每条一行。举个例子，一个典型的前后端全栈项目的.gitignore大概长这样：

# 依赖目录 node_modules/ vendor/ target/ # 构建产物 dist/ build/ out/ # 环境变量与密钥 .env .env.* *.pem # IDE配置 .idea/ .vscode/ *.iml # 系统文件 .DS_Store # 日志 *.log

为什么这一步要尽早做？因为Git一旦把某个文件提交进仓库，之后想把它移除就麻烦得多——需要修改历史或者用额外命令，而且密钥文件一旦提交到远程仓库，就等于泄露了。教给大家一个实用建议：写代码的过程中，每新增一个类型的文件，如果确定不需要进版本库，立刻加上.gitignore规则，不要攒到最后。

3.3 第一次提交：add、commit的完整动作

.gitignore准备好之后，就可以做首次提交了。

先看一下当前仓库状态：

git status

如果你没有犯前面说的"在错误目录初始化"的错误，这时候应该能看到项目文件列表，以及被忽略文件不显示或被标注。

把文件加入暂存区：

git add .

这里的.表示把当前目录下的所有文件（排除.gitignore忽略的）加入暂存区。也可以指定具体文件，比如git add src/index.js。第一次不建议逐文件add，效率太低，直接git add .检查一次状态最省事。

再执行一次git status，你会看到文件变成了绿色的"new file"状态，说明已经进入暂存区。

然后提交：

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

-m后面的内容是本次提交的说明。首次提交建议写清楚项目是什么、包含了什么模块，比如"初始化项目：搭建Spring Boot后端与Vue前端基础结构"，不要只写"init"或"first commit"这种没信息量的话。提交成功后，会输出类似[main 1a2b3c4]的信息，后面的哈希值就是这次提交的唯一标识。

到这里，本地仓库的代码历史就正式建立起来了。但注意，这个仓库目前只存在于你本机，别人看不到，也没法协作。下一步才是关键：把它推到远程仓库。

4. 绑定远程仓库：从建库到完成首次push

4.1 在Gitee创建远程仓库，并搞懂HTTPS与SSH的取舍

打开Gitee（或者GitHub）的网站，登录后进入"新建仓库"页面。有几个选项需要填：

• 仓库名称：建议和本地项目文件夹同名，比如my-shop，好对应。
• 仓库描述：简单说明项目用途，可留空。
• 是否初始化仓库：我建议全部先不勾选，不要自动生成README、.gitignore或许可证文件。原因后面解释。
• 开源还是私有：个人练习项目选私有，想展示到简历上、方便别人看就选公开。

创建完成后，页面会显示远程仓库的地址。通常有两种形式：

• HTTPS：https://gitee.com/你的用户名/my-shop.git
• SSH：git@gitee.com:你的用户名/my-shop.git

选哪种？我的建议是直接选SSH并花两分钟配置好密钥。使用HTTPS每次push都要输入用户名密码或令牌，虽然可以配置凭证管理器记住，但前期配置反而比SSH更麻烦。SSH配置一次公钥，之后的所有操作都免密，尤其是后面要自动化部署、在服务器上拉代码的场景，基本都依赖SSH。

4.2 生成SSH密钥并与Gitee关联

如果你还没有SSH密钥，执行：

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

一路回车即可，默认会在用户目录生成~/.ssh/id_rsa（私钥）和~/.ssh/id_rsa.pub（公钥）。私钥自己保存好，千万别发出去；公钥则要配置到远程仓库平台。

查看公钥内容：

cat ~/.ssh/id_rsa.pub

复制输出的整段内容，回到Gitee的"设置 -> SSH公钥"页面（GitHub对应位置在Settings -> SSH and GPG keys），粘贴保存。公钥名称随便填一个，比如"我的笔记本"。

验证配置是否成功：

ssh -T git@gitee.com

如果返回类似"Hi, 你的用户名! You've successfully authenticated"，说明SSH已经配好。这一步如果提示Permission denied，多半是公钥复制不完整、或者用了管理员权限执行命令导致读取密钥路径不对，重新检查公钥内容即可。

4.3 本地仓库关联远程地址，并完成首次push

现在回到项目终端，把本地仓库和刚才在网页上创建的远程仓库关联起来：

git remote add origin git@gitee.com:你的用户名/my-shop.git

这里的origin只是一个约定俗成的远程仓库别名，指代我们刚添加的远程地址。想确认有没有添加成功，执行：

git remote -v

会看到两条记录，分别对应fetch和push的地址，实际上指向同一个远程仓库。

接下来，把本地main分支推送到远程：

git push -u origin main

注意这几个参数的含义：-u是--set-upstream的简写，意思是把本地main分支和远程main分支关联起来。这样以后你再执行git push，Git就知道要推送给谁，不用每次都写完整命令。如果你在前面把默认分支名设置成了main，这里就写main；如果没设置，可能是master，写master即可。

执行之后，Git会要求你确认SSH密钥的指纹，输入yes回车。然后就是上传过程，成功后会看到类似这样的输出：

Enumerating objects: 45, done. Counting objects: 100% (45/45), done. Writing objects: 100% (45/45), 45 files, done. Total 45 (delta 3), reused 0 (delta 0) remote: Resolving deltas: 100% (3/3), done. To gitee.com:你的用户名/my-shop.git * [new branch] main -> main branch 'main' set up to track 'origin/main'

这时候去Gitee仓库页面刷新，就能看到项目文件已经上传了。从本地到远程，这条链路算是彻底打通了。

这里解释一下为什么建仓库时不要勾选"自动初始化README/.gitignore"：如果远程仓库已经通过网页初始化过，它就会自带一次commit，和你本地仓库的历史毫无关系。此时你执行git push，Git会拒绝推送，报错说远程有本地没有的提交，需要先git pull合并。对一个新手来说，第一次push就遇到"合并远程历史"这种问题，很容易懵。采用"远程全空、本地直接推"的做法，能完全避开这个坑，是最顺滑的首次push路径。

5. 日常开发中的迭代流程：提交、分支、合并与常见报错排查

上传成功只是起点。接下来的日常迭代里，你会反复用到的核心操作，集中在提交、分支和合并这三块。这一章我按"日常开发循环"的顺序来讲，最后附上高频报错的排查思路。

5.1 日常提交循环与commit --amend的两种用法

进入正常的开发节奏后，你会形成一个高频循环：改代码 -> 看状态 -> 暂存 -> 提交 -> 推送。

git status # 查看哪些文件被修改 git diff # 查看具体改了哪些内容 git add . # 暂存所有修改（谨慎：确认没有误加文件） git commit -m "feat: 新增登录接口" git push

每次提交前，用git diff看一眼改动内容，是个非常值得养成的好习惯。它能阻止很多事故——比如本地配置被别人改了、日志文件被误格式化、密钥文件意外暴露，这些问题在提交前查一下都能尽早发现。

再说一个新手经常问的git commit --amend。它的官方解释是"修改上一次提交"，实际上有两种常用场景。

场景一：commit信息写错了或漏写了文件。比如你刚提交了git commit -m "fix: 修复首页bug"，结果发现首页还有个样式文件没加进去。这时候：

git add src/styles/home.css git commit --amend -m "fix: 修复首页bug及样式"

这个操作会把你新加入的文件和上一次提交合并，并替换掉提交信息。woc注意：--amend会生成一个全新的提交哈希，所以只适合修改"还没有推送出去"的提交。如果已经把提交push到远程了再amend，会造成本地和远程历史不一致，推送就需要用git push --force，而强制推送可能覆盖团队的公共历史，非常不建议新手使用。

场景二：补全作者信息。有时候没配用户名邮箱就提交了，提交人是乱码。可以这样修复：

git commit --amend --author="正确的名字 <正确的邮箱>" --no-edit

--no-edit表示保持原来的提交信息不变，只改作者。

关于提交信息的规范，团队里协商一致即可，我个人的经验是：提交信息要像一个"短句子"，让别人不用打开代码就能知道这次改了什么。比如：

• feat: 新增商品列表接口
• fix: 修复移动端样式错位
• docs: 更新部署文档
• chore: 升级前端依赖版本

不建议用update、修改这种说不清改了啥的词，回头查历史时你会感谢当初写清楚的自己。

5.2 分支管理：切换、创建与合并冲突的处理

分支是Git最强大的能力之一，也是全栈项目多人协作的基础。简单来说，分支允许你在不影响主干的情况下，并行开发不同功能。

日常高频操作：

# 查看当前分支 git branch # 创建并切换到新分支 git checkout -b feature/login # 或新写法 git switch -c feature/login # 切回主干 git checkout main # 合并某个分支到当前分支（先确认你在目标分支上） git merge feature/login

合并冲突是新手最怕的问题，我拆解一下它发生的本质：两个人修改了同一个文件的同一段内容，Git不知道该听谁的。

假设你和同事都在改UserService.java，你改了方法A，他改了方法B，Git能自动合并——这是大多数情况。但如果你俩都改到了方法A，就会冲突。合并时Git会把冲突标记标出来，文件里会出现这样的内容：

<<<<<<< HEAD // 你当前分支的代码 ======= // 从feature/login分支带过来的代码 >>>>>>> feature/login

解决冲突的步骤很简单：

1. 用IDE或编辑器打开冲突文件。
2. 决定保留哪部分：保留当前分支的、保留对面分支的、或者手动整合成新代码。
3. 删掉<<<<<<<、=======、>>>>>>>这三行标记。
4. 保存文件，执行git add 冲突文件。
5. 继续git commit完成合并。

我个人的经验是：解决冲突时不要图快直接选一边。很多时候冲突双方逻辑都不是最终想要的，需要你理解上下文后重写。比如两个分支都新增了一个配置项，但配置名不一样，正确做法可能是保留一个统一名字，而不是二选一。

避免冲突的最佳策略，是保持分支短命。一个功能分支开发周期尽量控制在几天内，频繁把主干的更新合并回你的功能分支：

git fetch origin # 获取远程最新状态 git merge origin/main # 把远程主干合入当前分支

这样冲突在你自己的分支上提前暴露并解决，而不是最后合回主干时一次性爆发。

5.3 高频报错排查：not a git repository、push被拒等

这是最后一部分，我挑了新手最常遇到的几类git报错，每类给出排查思路而不是只给命令。

报错一：fatal: not a git repository (or any of the parent directories): .git

执行git status或git add时报这个错，说明当前目录不是一个Git仓库。原因通常是你在本节开头说的"在子目录里执行Git命令"或者"目录外"。解决办法：

pwd # 确认当前目录 cd 到项目根目录 # 回到包含.git目录的那一层

如果整个项目都没有.git目录，那就需要回到上一节重新执行git init。

报错二：remote origin already exists.

想给仓库添加远程地址，结果提示origin已经存在。说明你已经关联过一次了，不需要重复添加。可以先查看：

git remote -v

如果地址不对，删除重新添加：

git remote remove origin git remote add origin 正确的地址

不要尝试用git remote add origin xxx去覆盖已存在的origin，Git不允许，必须先移除。

报错三：push被拒绝，提示fetch first或non-fast-forward.

这个报错的核心原因，是远程仓库有你本地没有的提交。常见于：远程仓库在网页上初始化过（比如自动生成了README）、或者同事已经推送了新代码但你没拉取。正确操作顺序应该是先拉取合并再推送：

git pull origin main git push origin main

如果git pull之后出现合并冲突，就按上一节的方法解决。这里特别提醒：涉及多人协作的仓库，不要用git push --force去覆盖远端历史，一旦把别人的提交冲掉，恢复起来极其麻烦。

报错四：Git Bash输入中文乱码。

Windows用户常见，源自编码不一致。可以在Git Bash窗口上右键，选择Options -> Text，把编码设为UTF-8；提交信息写入时，尽量用英文能彻底规避这个烦恼。

下面用一个表格总结这些报错的排查要点：

到这里，从安装Git、初始化本地仓库、配置SSH、推送到远程，到日常迭代中的提交规范、分支合并、冲突处理和报错排查，全链路就完整了。你完全可以照着走一遍，把一个本地全栈项目干净利落地放进远程仓库。

最后分享一点个人习惯：我通常在项目的第一行代码写出来之前，就先建好远程仓库、写好.gitignore、完成首次push。后续每完成一个功能点，就产生一次清晰的commit。这样做的好处是，项目从一开始就有完整的历史脉络，出问题随时能回滚，跨设备开发时随时clone，简历上展示项目时也能直接甩一个仓库链接。Git这东西，光看教程永远学不会，真正上手推一次、合并一次、解决一次冲突，你才算真正拥有它。