企业官网建设流程全解析

说实话，Git和Gitee对我来说早就不只是工具，而是日常工作流的一部分。Git管版本、Gitee管托管和协作，两个配合起来，无论是个人项目还是团队开发，效率都能提上去不少。这篇东西说白了就是我长期使用中整理出的一份速查手册，不整虚的理论，直接聚焦日常开发里最高频的Git命令、Gitee操作，以及那些不看文档就一定会踩的坑。适合刚入门的新手照着一步步操作，也适合有经验的开发者随手翻一翻当备忘录。

1. 先把环境弄干净：Git安装与全局配置

1.1 跨平台安装的三种方式

Git的安装在不同系统上差别挺大，我逐个说下实测过的方案。

Windows上最省事的是去Git官网下载安装包，一路Next就行。但有几个选项要特别注意，建议在安装向导的“Adjusting your PATH”一步选择“Git from the command line and also from 3rd-party software”，这样以后在命令行里直接敲git就能用，很多开发工具也能自动识别到git。默认选项虽然也能用，但有些第三方软件找不到git，很容易出各种奇怪问题。还有换行符那一项，先别急着选，后面单独说。

macOS上如果装了Homebrew，一条命令搞定：brew install git。没装Homebrew的话，去官网下载dmg安装包也可以。Linux发行版更简单，Ubuntu/Debian用sudo apt install git，CentOS/RHEL用sudo yum install git，也是几秒钟的事。

装完先确认版本，终端里执行git --version，能正常输出版本号就说明安装成功。我习惯提示一下：版本别太老，Git 2.23之后才有git switch和git restore这两个命令，很多老博客写的命令在新版本里行为都不一样，版本对不上你照着敲可能就报错。

装完第一步别急着clone代码，先确认git版本，再配置用户信息。老项目的脚本里对git版本有要求的情况不少，版本太老有些命令行为会不一样。

1.2 全局配置和换行符陷阱

装完git第一件事就是配置用户名和邮箱，这个不配，commit的时候要么报错，要么提交记录里显示一堆问号，推送上去也没法关联到你的Gitee账号。

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

这里有个细节容易被忽略：Gitee读取的是提交记录里的邮箱，用它来关联账号。所以最好填你注册Gitee时用的邮箱，否则push上去了，Gitee那边不会正确挂到你的用户名下。

然后是换行符这个老坑。Windows的换行符是CRLF（回车+换行），Linux和macOS是LF（只有换行）。如果不做处理，同一份代码在Windows和Linux之间来回切换时，git会认为整个文件都变了，diff里全是莫名其妙的内容。我的做法是Windows上设置core.autocrlf true，macOS/Linux上设置core.autocrlf input。这样git在提交时自动把CRLF转成LF，检出时再按平台转回来，能省掉一大堆无关痛痒的变更。

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

再建议一条：预设默认分支名。早期git默认分支是master，现在新建仓库很多人习惯用main。与其每次init之后手动改名，不如直接全局配置：

git config --global init.defaultBranch main

这样以后git init出来的仓库默认就是main分支，省一步操作。

1.3 初始化一个本地仓库

新项目想纳入git管理，在项目根目录执行git init，目录里就会生成一个隐藏的.git文件夹，里面存着所有版本历史信息。之后正常add、commit就行。

不过更常见的情况是从Gitee上clone一个已存在的仓库到本地，那就不需要git init了。clone命令后面专门讲，这里先记住流程：新项目用init，已有远程项目用clone，两个操作二选一，别重复。

还有个高频场景：项目已经写了一段时间，代码量不小了，现在才想起来用git。这时候先别急着init，先想清楚哪些文件不该提交，比如bin目录、编译产物、本地配置、IDE的workspace文件。把.gitignore先写好再初始化，能避免很多麻烦。.gitignore的内容，我在后面第2节单独展开。

2. 日常用得最多的本地操作命令

2.1 提交前的三件套：status、add、commit

git status是使用频率最高的命令，没有之一。任何时候不确定当前仓库是什么状态，先敲git status。它会告诉你：哪些文件改了、哪些文件还没被git跟踪、当前在哪个分支、和远端比是领先还是落后。信息全且直观。我习惯每次提交前都敲一遍，确认要提交的东西符合预期再动手。

然后就是git add。add的作用是把文件从工作区放进暂存区，相当于告诉git“这些文件这次要提交”。几个常用形式：

git add . # 把当前目录所有改动加入暂存 git add 文件名 # 只添加指定文件 git add -p # 交互式逐块确认，适合一个大文件里混了多个改动

提交用git commit -m "提交说明"。提交说明的写法，我强烈建议带上类型前缀，比如feat:表示新功能，fix:表示修bug，docs:表示文档变更，refactor:表示重构。这个习惯一旦养成，看git log的时候一目了然，团队协作时别人也能快速理解每个提交的意图。

git commit -m "feat: 新增用户登录接口" git commit -m "fix: 修复订单列表分页错乱问题"

2.2 查看历史与对比差异

git log是查看提交历史的命令。默认输出比较朴素，我推荐记这个组合：

git log --oneline --graph --decorate --all

--oneline把每个提交压缩成一行，--graph用字符画显示分支分叉，--decorate显示分支和标签指向，--all显示所有分支。这条命令基本满足日常查看历史的所有需求。

想看某个文件具体改了什么，用git diff。三个形式的区别经常有人搞混：

git diff # 工作区和暂存区的差异，也就是还没add的内容 git diff --cached # 暂存区和上次提交的差异，也就是已经add的内容 git diff HEAD # 工作区和最新提交的差异，也就是所有未提交的改动

我的口诀是：不带参数看“还没add的”，带--cached看“已经add了的”，带HEAD看“相对于上次提交的全部改动”。

排查“这行代码是谁改的”“当时为什么这么写”时，git log -p直接看每次提交的具体改动非常有用。只想看某个文件的提交历史，用git log -- 文件路径。

2.3 .gitignore该写什么

.gitignore专门声明哪些文件不被git跟踪。很多新手漏掉它，结果把node_modules、target、.idea这种目录全推上去了，仓库变得又大又乱，别人clone下来还容易出问题。

常见忽略项包括：

• 编译输出目录：target、dist、build、out
• 依赖目录：node_modules、vendor
• IDE配置：.idea、.vscode（注意.vscode有些团队会保留公共配置）
• 本地环境文件：.env.local、application-local.yml
• 日志和临时文件：.log、.tmp
• 操作系统文件：.DS_Store、Thumbs.db

写.gitignore有一个关键顺序问题：已经被git跟踪过的文件，即使写了ignore规则也不会被忽略。必须先执行git rm -r --cached 文件路径把文件从git索引里移除，再写进.gitignore，然后提交一次。顺序反了，文件会一直赖在仓库里。这个坑我见人踩过无数次。

3. 连接Gitee：从注册到SSH密钥

3.1 创建Gitee仓库的细节

先在Gitee注册并登录，右上角“+”号里选“新建仓库”。几个字段要仔细看：仓库名称、是否私有、是否初始化仓库（自动生成README、.gitignore、开源许可证）。

Gitee免费账号就可以创建私有仓库，对个人项目和非公开代码来说很友好，不一定非要开源才能用。选择“公开”时，建议初始化时选一个开源许可证，否则别人看到你的代码也不知道能不能用。私有仓库的许可证可以先不选，等以后打算开源了再补。许可证具体怎么选，我在第6节专门讲。

创建完仓库，Gitee会展示一个页面，上面有HTTPS和SSH两种远程地址，还有几行提示命令。先别急着照抄操作，先把SSH密钥配好，不然每次push都要输账号密码，很烦。

3.2 SSH密钥配置与认证原理

SSH密钥可以理解成一对锁和钥匙：公钥放在Gitee服务器上，私钥留在本地。push的时候，git用私钥签名，服务器用公钥验证，验证通过就允许操作。这样既不用每次输密码，也比密码认证更安全。

生成密钥的命令：

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

推荐ed25519而不是传统的RSA 2048，因为ed25519密钥更短、生成更快、安全性也不差。如果你的git版本太老不支持ed25519，再用ssh-keygen -t rsa -b 4096 -C "你的邮箱"。

生成过程中会提示保存路径，直接回车用默认位置就行。还会让你输入passphrase，这是给私钥加的一层密码保护。不输入的话连接更方便，但私钥泄露了风险更大；输入的话每次连接都要输一遍，稍微麻烦。我个人的选择是本机不设passphrase，前提是电脑有全盘加密，如果你没有加密习惯，建议还是设上。

生成的公钥在~/.ssh/id_ed25519.pub文件里，用cat命令打开，复制全部内容。然后到Gitee右上角头像里的“设置”->“安全设置”->“SSH公钥”，粘贴保存。

验证是否配置成功：

ssh -T git@gitee.com

第一次连接会提示确认主机指纹，输入yes回车。配置没问题的话，会输出“Hi 用户名！You've successfully authenticated”之类的成功提示。

SSH认证失败是极高概率出现的问题。最常见的两个原因：一是公钥没粘贴完整，尤其是末尾部分；二是公钥添加到了别的平台而不是Gitee。排查顺序：先ssh -T git@gitee.com看输出，再检查本机~/.ssh下的文件名和权限，最后回Gitee页面核对公钥内容。

3.3 添加远端并完成首次推送

密钥配好之后，回到仓库页面复制SSH地址。

本地已有仓库的情况：

git remote add origin git@gitee.com:你的用户名/仓库名.git git branch -M main git push -u origin main

解释一下这三条：remote add把远程仓库地址绑定到本地origin这个名字；branch -M main把当前分支改名为main（如果你初始化时已经设置默认分支为main，这步可跳过）；push -u origin main把本地main分支推送到远程，-u参数记住关联关系，以后直接git push就行。

从Gitee拉新项目到本地，用clone：

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

clone完会自动带上远程仓库配置，不需要再手动add remote。

这里有个必踩的坑：创建仓库时如果勾选了“初始化仓库”（自动生成README），本地和远程就各有了一次不相关的首次提交，直接push会报错“failed to push some refs”。解决办法是先git pull --rebase origin main，把远程的README合进本地，再push。我第一次用Gitee时就卡在这里半小时，当时还不知道rebase是什么，现在回过头看，其实就是一次同步操作。

4. 分支管理实战

4.1 分支的创建、切换与合并

分支是git最核心、最能体现价值的功能。简单理解，分支就是一条独立的开发线，你可以在分支上随便改代码，不影响主分支和其他人的工作。

常用命令记这几个就够：

git branch # 查看本地分支列表，当前分支前面有星号 git branch 分支名 # 创建新分支 git checkout 分支名 # 切换分支 git switch 分支名 # 切换分支（新版更推荐） git checkout -b 分支名 # 创建并切换，最常用 git branch -d 分支名 # 删除分支

注意，从git 2.23开始官方推荐用git switch切分支、用git restore恢复文件，来替代checkout的一部分职责。但实际工作中老命令checkout还是无处不在，两种都要认得。

合并分支的命令是git merge。在feature分支上开发完新功能想合回main，先切回main，再执行git merge feature。git会把两个分支的历史合并到一起，产生一个合并提交。

4.2 合并冲突的解决流程

两个分支改动了同一个文件的同一行，git就不知道谁对谁错，会产生冲突。冲突发生后，git status会告诉你哪些文件冲突了，打开文件会看到类似这样的标记：

<<<<<<< HEAD 这里是当前分支的内容 ======= 这里是合并进来的分支的内容 >>>>>>> feature

解决冲突就是手动把这段内容改成你想要的样子，删掉那些标记行，然后git add这个文件，再git commit。注意，git不会替你判断谁的改动是对的，这个决策必须人来做。

我踩过的坑是：合并不一定只在merge时发生，git pull的时候也可能触发冲突，因为pull本质上是fetch加merge。遇到pull冲突别慌，解决流程和merge冲突完全一样。有一个缓解技巧：git pull --rebase比git pull产生冲突的概率低一些，因为rebase会把本地提交一个个应用到远端最新代码上，而不是一次性做一个合并。

4.3 rebase与merge该选谁

这是个能引发争论的话题，我从实用角度说我的选择。

merge保留完整的合并历史，git log --graph里能看到清晰的“分叉再合并”结构。好处是保留了真实的时间线，坏处是历史里会出现很多“Merge branch ...”这样的提交，时间长了有点乱。

rebase做的事情是把当前分支的提交“重新移植”到目标分支的顶端，效果是提交历史变成一条直线，非常干净。

我的习惯是：个人开发的分支、还没推送过的提交，用rebase整理历史；团队共享的分支、已经推送过的提交，用merge。原因是rebase会改写提交的哈希值，如果你rebase了一个别人也在用的分支，会引发一连串冲突和混乱。所以有个原则：不要把rebase用在共享分支上。

实际场景举例：feature分支是从main分出来的，开发期间main来了几个新提交，想把main的新改动同步到feature，执行git rebase main。成功后feature看起来像是从最新main上长出来的，逻辑很干净。前提是feature只有你在用。

5. 回滚与撤销：救命的命令

5.1 三个撤销场景

开发中总会遇到改错了想撤销的情况，按场景拆开讲。

场景一：文件还在工作区，没add。改了半天的东西全不想要了，执行git restore .，当前目录所有未暂存的改动全被丢弃。只想撤销单个文件就git restore 文件名。这个操作不可逆，执行前先用git diff看一眼到底改了啥。

场景二：已经add了，但还没commit。撤销暂存用git restore --staged 文件名，文件回到未暂存状态，但改动内容还在。

场景三：已经commit了，但还没推送到远程。这种最幸福，用git reset可以随心回退：

git reset --soft HEAD~1 # 撤销最近一次提交，改动保留在暂存区 git reset --hard HEAD~1 # 撤销提交并且丢弃改动，回到上次提交的状态

--hard慎用，它会连工作区一起重置，丢了的代码找不回来。如果你不确定改动还有没有用，先git stash或复制一份备份，再操作。

5.2 commit --amend怎么用

commit --amend的作用是修改最近一次提交。最常见场景是提交信息写错了，或者漏了一个文件。

改提交信息：

git commit --amend -m "新的提交说明"

补漏文件：

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

--no-edit的意思是不重新编辑提交说明，沿用之前的信息。

有一个关键禁忌：amend本质是把原提交替换成新提交，会改写提交哈希。如果上一次提交已经推送到远程，并且分支是多人协作的，amend之后强推会导致别人本地的历史对不上。我的规则是：只有还没推送的提交才用amend，已经推送了就老老实实再提一个新提交。

5.3 用reflog找回丢失的提交

手滑执行了git reset --hard，提交丢了怎么办？别慌，git有一个“后悔药”：reflog。

git reflog会显示本机所有HEAD移动过的记录，包括每一次reset、checkout、commit。每条记录前面有哈希值，你误删的那次提交就藏在里面。

找回方法：

git reflog git checkout 哈希值

或者直接重置：

git reset --hard 哈希值

这个命令能恢复绝大部分误操作，但有两个前提：一是reflog记录还在，二是被找回的提交对象还没被git的垃圾回收机制清理。发现误删后越早恢复成功率越高。

我实测过几乎所有的git“误删除”都能靠reflog找回来，只要你在本地仓库里操作过。唯一救不了的是那些从未commit过的工作区改动，所以重要改动尽量早提交，这个习惯值得养成。

6. Gitee特有的几个实用功能

6.1 Gitee Pages部署静态站点

Gitee Pages可以把仓库里的静态页面发布成一个能通过网址访问的站点。对个人博客、项目文档、前端Demo来说很实用。

部署流程：仓库里放一个包含index.html的静态页面目录，到仓库页面的“服务”菜单里找到“Gitee Pages”，选择要发布的分支和目录，点击启动。部署完成后，Gitee会给一个默认的gitee.io后缀域名，也可以绑定自己的域名。

需要注意几点：Gitee Pages要求账号完成实名认证；启动部署后要等平台审核，审核通过后才能正常访问。内容必须符合平台规定，这没什么好讨价还价的。我的使用场景是把技术文档仓库部署成在线手册，再绑一个自定义域名，团队内部访问起来比翻本地文件方便很多。

6.2 大文件上传与Git LFS

Gitee仓库有单文件大小限制，普通方式上传超过一定大小的大文件会被拒绝。这种情况需要Git LFS（Large File Storage）。

LFS的思路是：仓库里只存一个文本指针，真正的二进制大文件放在LFS存储服务器上。clone仓库时，git按需拉取LFS文件，不会让仓库体积爆炸。

使用步骤：

git lfs install # 安装LFS，只需要执行一次 git lfs track "*.zip" # 声明要跟踪的文件类型 git add .gitattributes # track后生成的.gitattributes要提交 git add 大文件 git commit -m "添加大文件" git push

注意，LFS不是完全免费的，Gitee对LFS的存储空间和流量有配额限制，免费用户额度很小。偶尔传一两个大文件够用，如果是音视频素材这类重度场景，还是建议换对象存储服务。

如果大文件只是自己用，不一定要进仓库。放到网盘或内网共享盘，在README里写个下载说明，这招治标不治本，但对个人项目来说最省事。

6.3 开源许可证怎么选

创建公开仓库时，Gitee会让你选许可证。很多人纠结，其实选错比不选要好。公开仓库没有许可证，意味着“保留所有权利”，别人虽然能看到你的代码，但法律上不允许使用。

几个常见许可证的区别：

• MIT：非常宽松，别人想怎么用都行，只要保留版权声明。适合个人项目、工具类、库类。
• Apache-2.0：比MIT多一些条款，比如专利授权，适合希望更正式一点的项目。
• GPL-3.0：要求任何修改和分发代码的人，也必须以GPL协议开源。适合希望代码永远保持开源的项目，但对商业使用不友好。

我的建议：个人工具、博客主题选MIT；公司项目要和法务确认；如果你希望别人改进后的代码也必须开源，才考虑GPL。还有一个实用小知识：改许可证方案没问题，但旧版本还是按旧许可证执行，所以越早定越好。

6.4 Gitee仓库能包含子项目吗

这个问题其实就是问monorepo和submodule。Gitee本身没有“子项目”这种特殊概念，一个仓库就是一个仓库，但有两种变通方案。

第一种是monorepo：一个仓库里放多个独立项目，用目录区分。比如一个前端仓库底下有admin、mobile、docs三个子目录，各自有独立的package.json。这种方式管理简单、体积可控、权限统一，是大多数团队实际采用的。缺点是多个项目共用一条提交历史，版本发布规则要自己约定好。

第二种是Git Submodule：在一个仓库里引用另一个Git仓库。当你要把公共组件仓库直接嵌入项目时，可以：

git submodule add git@gitee.com:用户名/公共组件仓库.git

别人获取代码时用git clone --recursive，子模块会一并拉取。submodule的坑在于子模块指针容易失联，团队成员忘了拉子模块导致编译报错的情况很常见，维护成本不低。小型团队我更推荐monorepo。

7. IDE集成：IDEA和VS Code配合Gitee

7.1 IDEA拉取与推送项目

IDEA内置了完整的Git支持，不需要额外装插件。第一步是把本机git路径配好：File -> Settings -> Version Control -> Git，Path to Git executable指向git安装路径。

用SSH方式操作Gitee时，IDEA里不需要登录Gitee账号，只要本机SSH密钥配好了，IDEA直接复用即可。

从Gitee拉取项目到IDEA的流程：File -> New -> Project from Version Control，粘贴仓库SSH地址，选择本地目录，点Clone。IDEA会自动识别Maven、Gradle或前端项目，非常顺滑。

日常提交推送：修改文件后文件会变色（新增蓝色、修改红色），在Commit窗口勾选要提交的文件，写提交信息，点Commit或Commit and Push。IDEA的Changes面板比命令行直观得多，适合不熟悉命令行的新人。不过IDEA里的分支操作也比较全，右键分支名可以checkout、merge、compare，我经常在IDEA里完成大部分git操作。

7.2 VS Code的Git面板

VS Code左侧活动栏的源代码管理图标就是Git面板。它有几点做得很好：文件内直接显示改动行；提交信息输入框集成在面板上；push、pull都有对应按钮。Ctrl+Shift+P输入Git: Clone，输入仓库地址就能可视化clone。

我特别推荐新人用VS Code的源代码管理面板入门Git，因为每一步都有可视化反馈。但有几个操作还是得回终端：git rebase、git stash、git reset --hard，集成面板要么不支持，要么提示不够直观。所以别指望IDE完全替代命令行，两条腿走路效率最高。

7.3 多远端协作的技巧

一个仓库绑定多个远端地址，在和多个平台协作时会用到。默认远端叫origin，可以再添加一个：

git remote add backup git@gitee.com:用户名/仓库名.git git remote -v # 查看所有远端 git push origin main # 推送到默认远端 git push backup main # 推送到备份远端 git fetch backup # 拉取备份远端的提交，但不自动合并 git merge backup/main # 手动合并

多远端在参与开源项目时很常见：主仓库在Gitee上，额外挂一个远端做备份，或者同时参与其他项目。注意一点：git push不带参数默认推送到origin，别养成不带参数的习惯，免得推错地方。

8. 高频问题排查实录

8.1 SSH认证失败排查

SSH认证失败几乎是每个git新手都会遇到的。典型报错是“git@gitee.com: Permission denied (publickey)”。按我的排查顺序来：

ssh -T git@gitee.com # 第一步，测试连接，看报错信息 ls ~/.ssh # 第二步，检查密钥是否存在 cat ~/.ssh/id_ed25519.pub # 第三步，查看公钥内容 git remote -v # 第四步，确认用的是SSH地址 eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519 # 第五步，可能是ssh-agent没启动

还有一个容易被忽略的：企业电脑的防火墙或安全策略可能拦截SSH端口，导致连接超时。这种情况可以改用HTTPS地址配合访问令牌的方式拉取推送。Gitee支持生成访问令牌，HTTPS方式下输入用户名和令牌就能认证，虽然每次要输，但至少能用。

8.2 推送被拒绝

推送被拒绝的典型场景是本地和远端的历史不一致，报错一般是“Updates were rejected because the remote contains work that you do not have locally.”

解决办法有两种。远端确实有新提交并且你想保留，执行git pull --rebase origin 分支名，把远端提交合到本地再推送。确定本地提交是完整的、远端的改动都不要，再考虑git push --force或git push --force-with-lease。但强制推送会覆盖远端历史，多人协作的分支千万不要force，一旦误伤队友的提交，那场面很难收拾。--force-with-lease比--force安全，它只有在远端分支没有你预期之外的提交时才允许推送，相当于加了一道保险。

8.3 大小写问题引发的bug

文件大小写问题在Windows和macOS上坑过不少人。默认文件系统大小写不敏感，你在一个环境创建了Utils.java，另一个环境改成util.java，git可能不识别这是重命名还是新文件，尤其跨平台协作时，会导致编译找不到类。

缓解方法：

git config core.ignorecase false

但这个配置只影响后续操作，已提交过的历史问题还是要手动处理。最稳妥的做法是先把这个文件改成一个临时名字，比如util.bak，提交一次，再改回正确的大小写，再提交一次。让git真正记录一次删除和一次新增，这样不同平台都能强制同步。

8.4 其他高频小坑速查

整理了一张问题速查表，遇到问题先对着查：

还有一个我提了很多次但值得再强调的：.gitignore不生效，本质原因是文件已经被git跟踪了。git的ignore规则只对未跟踪文件生效，想让它停用跟踪，必须先git rm --cached再提交。

最后再分享一个小技巧：遇到拿不准的命令，先git status看状态，再git log看历史，最后才决定用什么命令操作。这个顺序看起来简单，但能避免绝大多数误操作。我现在遇到再复杂的git问题，也还是靠这招稳住局面。多折腾几次，这些命令自然就长在肌肉记忆里了。