企业官网建设流程全解析

不论你是刚把系统装成 Linux、准备搞开发，还是已经用了一阵子但一直只用 GitHub，Gitee 在 Linux 下的使用都是值得认真捋一遍的事。很多人觉得码云无非就是国内版的 GitHub，把网址换一下、命令照抄就行，实际用下来坑不少：认证方式不一样、仓库权限模型有差异、大文件存储得单独配、CI 构建规则也完全是另一套思路。这篇文章我就以平时在 Linux 终端里的真实操作为主线，把这套流程从头到尾过一遍，既讲命令怎么写，也讲为什么这么写。

先说清楚这篇文章适合谁：刚接触 Linux、想在 Gitee 上托管代码的初学者，能从零把环境搭起来，跑通第一次 push；已经有一定 Git 基础但没用过 Gitee 的开发者，能避开我在实际使用中踩过的认证和分支保护相关的坑；至于想在 Gitee 上做团队协作或者自动化部署的人，后面几个章节也覆盖了 WebHook、Release 和 CI 的基础玩法。我尽量把命令、参数、排查思路都写得能直接复现，不会绕弯子。

1. 为什么在 Linux 上优先考虑 Gitee

先聊几句背景。Linux 下用 Git 托管服务，选择无非就是 GitHub、Gitee、自建 GitLab 这几类。GitHub 对国内网络环境不够友好，clone 和 push 的速率经常不稳定，这个属于客观情况；自建 GitLab 维护成本高，要单独一台机器跑、还得处理备份和升级；Gitee 的优势在于仓库地址在国内，终端里走 HTTPS 协议的时候连接速度明显更快，而且很多开源项目在国内同步代码时都会把 Gitee 作为镜像站点。

我自己实际测试过，同一台服务器、同一个仓库，往 Gitee push 的平均耗时大约是推送 GitHub 的三分之一到四分之一，这个差距在频繁提交的时候体感很强。对国内公司的开发团队来说，Gitee 还提供企业版，支持私有仓库的成员权限管理、MR（Merge Request）评审流程、任务看板，这些在 Linux 服务器上做自动化部署时非常实用。个人开发者则可以用免费版创建私有仓库，虽然不是完全无限制，但日常学习和作品集展示足够了。

我在 Linux 下推荐 Gitee 还有一个原因：它支持 SSH 协议的 git@ 连接方式，这个跟 GitHub 的 SSH 方式几乎一致，配置好公钥之后，push 和 pull 都不需要反复输密码，非常适合写脚本和配置定时任务。而且 Gitee 的 WebHook 功能可以直接向 Linux 服务器上的服务程序发送 POST 请求，这对做自动化部署来说至关重要，后面我会专门展开。

2. 环境准备：Linux 下的 Git 安装与基础配置

2.1 安装 Git 并确认版本

在开始操作 Gitee 之前，得先保证 Linux 系统里已经装了 Git。不同发行版的包管理器命令不一样，我平时接触比较多的是 Debian/Ubuntu 系和 CentOS/RHEL 系，分别执行下面两条：

# Debian / Ubuntu sudo apt update sudo apt install -y git # CentOS / RHEL sudo yum install -y git

如果是 Arch Linux，那就是sudo pacman -S git。装完之后执行git --version，我建议至少是 2.20 以上的版本，太老的版本对 SSH 密钥格式、协议支持方面会有一些小问题。这里有个容易忽略的点：刚装完的 Git 默认编辑器是 vi，很多新手在 commit 的时候不小心进到 vi 界面里不知道怎么退出，我一般会在全局配置里顺手改成 nano 或者 vim，看个人习惯。

2.2 配置用户名和邮箱

Git 提交记录里会带上作者信息，Gitee 的提交记录页也会根据这个信息来关联账号。这里说的用户名和邮箱不一定非要跟 Gitee 注册信息完全一致，但为了提交记录能够正确在 Gitee 上显示头像和主页链接，强烈建议保持一致。

git config --global user.name "你的用户名" git config --global user.email "你的邮箱@example.com"

可以用git config --list来检查当前生效的配置。这里有个细节：--global是写入~/.gitconfig文件，而每个仓库还可以有自己的.git/config，优先级是仓库级配置高于全局配置。如果你的某个项目里需要以不同的身份提交，比如公司的仓库用公司邮箱，可以在仓库目录内单独执行一次git config user.name和git config user.email，不添加--global参数就行。我在实际工作中就遇到过忘记改局部配置导致提交记录跑到旧账号下的情况，查起来很费劲。

2.3 设置默认分支名和换行符处理

Gitee 上新建仓库时默认分支名是 master，但很多新项目已经转向 main。为了减少不必要的麻烦，我会在全局配置里设置默认分支名：

git config --global init.defaultBranch main

还有一个绕不开的问题是换行符。Windows 环境下 Git 默认会做 CRLF 转换，Linux 下默认是 LF。如果你在 Linux 上拉取一个 Windows 开发者维护的仓库，经常会出现“整个文件都显示被修改”的错觉，其实就是换行符变了。我建议 Linux 用户明确设置：

git config --global core.autocrlf input

input的含义是提交时把 CRLF 转成 LF，checkout 时不转换，这符合 Linux 端的习惯，也能避免仓库里混入大量不统一的换行符。

3. 认证配置：从 HTTPS 密码到 SSH 密钥的完整切换

这一节是重点，也是很多人在 Linux 下第一次用 Gitee 时最容易卡住的地方。

3.1 HTTPS 方式与时区差异的坑

最开始接触 Gitee，最省事的做法是走 HTTPS 协议：

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

但新手往往会在这里撞上第一个坑：Gitee 很早就不再支持在终端里直接用账号密码进行 HTTPS 认证了，而是要求使用私人令牌（Personal Access Token）。当你输入用户名之后，密码那一栏要填的不是 Gitee 登录密码，而是去 Gitee 网页端生成的私人令牌。这个设计跟 GitHub 一致，主要是为了安全考虑，防止密码在第三方平台被记录。

生成路径是：Gitee 网页右上角头像 -> 设置 -> 安全设置 -> 私人令牌 -> 生成新令牌。生成的时候可以选择令牌权限，我一般建议只勾选projects权限里的读写即可，不要图省事直接全选。拿到令牌之后复制保存好，因为它只显示一次。

如果不想每次 push 都输入令牌，可以在 Linux 上启用 Git 凭据存储：

git config --global credential.helper store

这会把令牌明文存到~/.git-credentials文件里，对个人电脑来说问题不大，但在服务器上这么做相当于把钥匙放在了进门垫子下面，自己权衡。更稳妥的方式是用credential.helper cache，设定过期时间：

git config --global credential.helper 'cache --timeout=3600'

不过说实话，在 Linux 上我最终推荐的是 SSH 方式，长期使用更省心。

3.2 生成 SSH 密钥对并添加公钥

SSH 方式的核心是密钥对。生成命令如下：

ssh-keygen -t ed25519 -C "你的邮箱@example.com"

我推荐使用 ed25519 算法，比传统的 RSA 更安全、更短，而且 Gitee 完全支持。如果出于某些原因必须用 RSA，可以换成ssh-keygen -t rsa -b 4096 -C "你的邮箱"。

生成过程中会让你选择保存路径，默认是~/.ssh/id_ed25519，直接回车即可。如果该路径下已有同名文件，会提示是否覆盖，务必确认这是不是你需要保留的密钥。接着会让你设置 passphrase，也就是私钥的解锁密码。为了安全性建议设置一个，但在服务器或者自动化脚本里，设置了 passphrase 会导致 push 时需要手动输入密码，反而不方便。我个人的做法是：个人开发机设置 passphrase，服务器上生成专属密钥不设 passphrase，并且限制该服务器的用途，只作为一个受控的部署账号。

生成完成后，查看公钥内容：

cat ~/.ssh/id_ed25519.pub

复制输出的一整行，格式是ssh-ed25519开头的一串。然后打开 Gitee 网页端：头像 -> 设置 -> 安全设置 -> SSH 公钥 -> 添加公钥，粘贴进去，标题可以随便填，方便自己认出来是哪台机器。

3.3 测试 SSH 连接

添加好公钥后，在终端验证一下：

ssh -T git@gitee.com

如果看到欢迎信息，类似 "Hi 用户名! You've successfully authenticated, but GITEE.COM does not provide shell access."，说明 SSH 认证已经通了。如果你在服务器上测试时提示权限拒绝，多半是公钥没粘贴完整，或者粘贴时多了空格换行。另外一个容易被忽略的点是，SSH 客户端的默认端口是 22，Gitee 服务器如果响应慢，可以尝试配置走端口 443：

# 在 ~/.ssh/config 中添加 Host gitee.com HostName gitee.com User git Port 443

这个配置偶尔能绕过某些网络环境下对 22 端口的限制，属于实战小技巧，我在远程办公室网络下遇到过可以用 443 连上但 22 连不上的情况。

3.4 切换 remote 地址

SSH 配置好之后，需要把本地仓库的远程地址从 HTTPS 切换成 SSH，或者直接 clone 时就用 SSH 地址。Gitee 仓库主页右上角有一个克隆/下载按钮，下拉列表里有 HTTP 和 SSH 两种地址。SSH 地址的格式是：

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

如果你已经用 HTTPS 克隆了仓库，切换方法：

git remote set-url origin git@gitee.com:用户名/仓库名.git

查看确认：

git remote -v

这会儿你会看到 origin 指向 SSH 地址。之后再进行 push 和 pull 就不再需要输入密码了。

4. 日常操作全流程：从克隆到推送的完整工作流

配置完成，就可以进入日常的开发循环了。这一节我从具体命令和操作习惯两个层面来讲，尤其会强调分支管理和提交信息规范，因为这是团队协作中最容易出问题的地方。

4.1 克隆仓库与工作目录初始化

如果是从零开始，最直接的方式是：

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

克隆完成后，仓库目录下会有.git隐藏目录，所有的版本历史都在里面。这里补充一个有用的参数，如果你只想要某个分支或者只想要最新一版的代码而不需要历史，可以加--depth 1：

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

这个浅克隆写法在拉一个大仓库的时候能明显节省时间，特别适合只需要在服务器上部署、不需要完整历史记录的场景。

如果你是先在本地创建了项目，希望推送到 Gitee 上的空仓库，操作顺序是：

mkdir 项目名 cd 项目名 git init git add . git commit -m "初始提交" git remote add origin git@gitee.com:用户名/项目名.git git push -u origin main

这里有一个新手的经典误区：git add .会把当前目录下所有文件都加进去，包括了一些编译产物、临时文件、IDE 配置等。正确做法是先在项目根目录创建.gitignore文件，把不需要纳入版本控制的目录和文件排除掉。我在 Linux 下最常见的场景是 Python 项目的__pycache__、*.pyc，Node 项目的node_modules，以及各类 IDE 的.idea/.vscode目录。这些如果不忽略，后续每次git status都会看到一堆乱七八糟的变更。

4.2 日常提交：status、add、commit 的组合节奏

在 Linux 终端下工作的好处是，Git 命令可以跟其他命令行工具完美配合。我的日常节奏是：写代码时频繁使用git status查看变更，确定要提交哪些文件再git add，然后提交并推送：

git status git add 具体文件或目录 git commit -m "feat: 添加用户登录接口" git push origin 当前分支名

提交信息这一块，我强烈建议遵循一个简单的规范：前缀表达类型，正文描述内容。比如fix:表示修复 Bug，feat:表示新功能，docs:表示文档变更，refactor:表示重构。这样在查看提交历史时，一眼就能看出每个提交的性质，配合 Gitee 的提交记录页面能快速定位问题。这里有个经验：不要用git commit -m去写超长的说明，如果提交信息需要分段，直接用git commit打开编辑器来写，格式更清晰。

Gitee 的 push 默认可能被分支保护规则限制，如果你在 Push 时报错 remote rejected，大概率是目标分支设置了保护，不允许直接提交。这个在团队的仓库里很常见，个人仓库则不会遇到，后面章节我会单独说。

4.3 分支操作与合并策略

分支是 Git 的核心优势。在 Linux 下我常用的分支命令：

git branch # 查看本地分支 git branch 新分支名 # 创建新分支 git checkout 新分支名 # 切换到新分支 git switch -c 新分支名 # 创建并切换（Git 2.23+ 推荐） git branch -d 分支名 # 删除分支

合并分支的标准动作：

git checkout main git pull origin main git merge 功能分支名 git push origin main

在 Gitee 上操作分支时，还有一个网页端强相关的功能叫 Pull Request（Gitee 里叫 Pull Request，缩写 PR）。当你把功能分支推到 Gitee 远端的仓库后，可以去网页端发起一个 PR，让代码评审人看变更、评论、然后再合并到主分支。相比在本地直接把分支合并到 main 再 push，PR 流程的优势在于有审查记录、有讨论痕迹，出了问题能追溯。个人项目也许觉得这股流程太重，但团队项目强烈建议走 PR，不要直接把 main 分支当作个人开发分支乱推。

4.4 拉取最新代码：fetch 与 pull 的区别

日常操作里还经常遇到git pull和git fetch。很多新手会混淆这两个命令。简单来说，git fetch只是把远端的新提交下载到本地仓库，但不会修改你当前的工作目录和分支指向；git pull等于git fetch加git merge，它会把远端的新提交直接合并进当前分支。在团队协作中，我建议先用git fetch看远端变化，确认不会产生冲突再去 pull，尤其是多人同时修改同一个文件时，直接 pull 很容易进入合并冲突界面。

如果 pull 的时候发现有冲突，冲突文件里会出现类似：

<<<<<<< HEAD 当前分支的内容 ======= 远端分支的内容 >>>>>>> origin/main

这时候需要手动编辑文件，保留希望的内容，删除冲突标记，然后重新git add和git commit。在 Linux 终端里处理冲突不如图形化工具直观，但操作熟练后效率极高。Vim 或其他编辑器配合搜索功能定位<<<<<<<就能逐个处理；也可以用git mergetool调用可视化工具，但我个人在服务器环境下更习惯手动处理，因为服务器上通常没装图形界面。

5. 仓库管理进阶：Gitee 的 Releases、Pages 与 WebHook

日常的 Git 命令掌握之后，Gitee 还提供几个跟 Linux 使用场景深度相关的高级功能，值得认真说。

5.1 通过 Releases 管理版本产物

Gitee 的 Releases 功能本质上是一个文件存储和发布系统。你可以在网页端手动上传编译打包好的文件，比如app.tar.gz、config.yaml、installer.run，给它们打上版本号v1.0.0，然后在 Linux 服务器上用wget直接拉取：

wget https://gitee.com/用户名/仓库名/releases/download/v1.0.0/app.tar.gz

这个用法在自动化部署脚本里非常实用，因为 Release 文件的下载地址是稳定的，只要打新版本号就不会覆盖旧文件。对比之下，如果你把编译产物直接推到仓库的某个分支里，会让仓库体积迅速膨胀，而且每次拉取都要把整个历史下载一遍，非常低效。

我在实际项目中，习惯用一个简单的脚本在 Linux 下自动打包并通过 Gitee 的 API 上传到 Release：

# 先计算文件的 SHA256 校验值 sha256sum dist/app.tar.gz

然后调用 Gitee 的 Open API 创建 Release 并上传附件。具体 API 的使用在官方文档里有详细说明，我这里不展开每一个参数，只提醒一点：调用 API 需要用到私人令牌，跟前面生成的那个一致，权限需要勾选projects的写入权限。这种方式特别适合要做定时发布或者 CI 集成的团队，避免每次都要人工网页上传。

5.2 使用 Gitee Pages 部署静态站点

Gitee Pages 是 Gitee 提供的静态网站托管服务。适合部署个人博客、项目文档站点、纯前端的演示页面。它的用法很直观：在仓库中放入静态文件（HTML/CSS/JS 或者由文档工具生成的静态站点），然后在 Gitee 网页端进入仓库 => 服务 => Gitee Pages，选择部署分支和目录，点一下启动，稍等片刻就能在 Gitee 分配的域名上访问到你的站点。

在 Linux 下与 Pages 配合最常用的场景是：用 MkDocs 或 VuePress 这类文档工具在本地构建静态网站，然后把生成站点目录的产物推送到仓库的gh-pages分支（或者你指定的分支）。这里有几个实际使用中必须注意的细节：

• Gitee Pages 的免费套餐在部署时会重新编译一次，如果你使用的是自定义域名，需要先在网页端配置好，否则会出现访问域名不一致的问题。
• 仓库如果包含敏感信息，千万不要部署到 Pages 上，私有仓库的 Pages 服务有访问控制，但公开部署的内容就是人人可见。
• 静态站点的资源均为相对路径引用时，在子目录部署才不会乱；如果你直接把构建产物放在仓库根目录，且没有设置正确的 base 路径，CSS 和 JS 经常 404。我刚开始用 VuePress 时就在这里栽过，后来统一在配置文件里把 base 设置成仓库名加斜杠。

5.3 WebHook 与服务器自动化联动

WebHook 是 Gitee 与 Linux 服务器自动化的一个桥梁。原理很简单：你在 Gitee 上给某个仓库配置一个 WebHook，URL 指向你的 Linux 服务器上的某个服务接口，当仓库发生指定事件（比如 push、提交 PR、创建 Release）时，Gitee 会向这个 URL 发起一个 HTTP POST 请求，请求体里有仓库、提交人、提交信息等数据。

在 Linux 上最常见的应用是自动部署：当你推送到远程 main 分支时，Gitee 触发 WebHook，你的服务器收到请求后执行一个部署脚本，把最新的代码拉下来，重启服务。这个链路看似简单，真正在生产环境里跑起来有三大注意事项：

第一，WebHook 的 URL 必须能被 Gitee 公网访问到。如果你的服务器在 NAT 后面、没有公网 IP，可以用内网穿透工具或者干脆部署在云端服务器上，但穿透工具的选择不在本文讨论范围内。第二，光收到 POST 还不够，消息体是 JSON 格式，你需要解析字段来判断这次推送的分支是哪个。我的习惯是用 Python 的 Flask 或 Node.js 的 Express 写一个小服务，收到请求后判断 branch 字段是否为refs/heads/main，是才执行部署脚本。第三，一定要在服务端校验 Gitee 请求的签名或者至少校验一个自定义 Token 字段，否则任何知道 URL 的人都可以触发你的部署脚本，有安全风险。

6. 团队协作与权限体系解析

到这里，单人的使用方法基本完整。但 Gitee 在 Linux 下最有价值的应用场景之一还是团队协作，这一节把权限模型和几个常见的协作坑讲透。

6.1 角色权限：从访客到管理员的层级差异

Gitee 仓库的成员角色分为几个层级：访客、开发者、管理员、所有者。不同角色的权限差异直接影响你在 Linux 下的 Git 操作范围。

• 访客只能查看和克隆公开仓库，不能 push。
• 开发者可以 clone、pull、push，也可以创建分支，适合日常开发人员。
• 管理员在开发者基础上可以管理仓库设置、成员权限以及分支保护规则。
• 所有者是仓库的创建者，权限最高，包括删除仓库的操作，但也有额外的保护限制。

如果你在 push 时收到permission denied的报错，且 SSH 认证已通过，大概率是你的账号在仓库成员角色列表里是访客级别，需要让管理员提升权限。这个问题在团队里经常出现，新人加入后管理员忘记添加为开发者，一上午都会卡在 push 环节。

6.2 分支保护与 Code Review 的落地

Gitee 的分支保护规则值得认真配置。在仓库的“管理”选项里可以设置受保护分支，对 main 分支启用保护后，通常会有这些约束：不允许直接推送，必须通过 Pull Request 合并；要求 PR 至少经过一个评审人批准才能合并；还可以设置不要强制推送。

这些规则对 Linux 终端的使用习惯来说是一个很关键的调整：直接git push origin main会失败，但如果你 checkout 一个新分支、提交后 push 新分支，再到网页端发起 PR，一切就顺理成章了。我建议团队的每个成员都习惯这样的流程，而不是为了省事关掉分支保护。

还有一个细节：Gitee 的合并方式有 merge commit 和 squash 两种。squash 方式会将整个 PR 的所有提交合并成一个提交，历史更干净；merge commit 保留完整开发历史。如果团队追求简洁的提交历史，建议统一用 squash，否则分支合并后可能有一堆Merge branch 'feature' into main的噪音提交。

6.3 多仓库与 Fork 工作流

Gitee 上参与开源项目时，常见的工作流是 Folk。你无法直接往别人仓库的 main 分支 push，所以把别人的仓库 Fork 到自己账号下，得到一个副本仓库，然后：

git clone git@gitee.com:你的用户名/原仓库名.git cd 原仓库名 git remote add upstream git@gitee.com:原作者用户名/原仓库名.git

这里加了名为upstream的远程地址，指向原作者的官方仓库。之后你可以从upstream拉取最新代码：

git pull upstream main

再把你自己修改的分支 push 到origin（即你的 Fork 仓库），最后在 Gitee 网页端从你的 Fork 分支向原仓库发起 Pull Request。这是开源项目贡献的标准流程，也适用于公司内部采用“集中式 + 个人 Fork”模式的团队。注意，Fork 出来的仓库默认是原仓库的快照，需要经常同步 upstream 的最新代码，不然你的 PR 可能因为冲突迟迟无法合并。

7. 常见问题排查与实战速查表

这一节整理我在 Linux 下使用 Gitee 时遇到的频率最高的几个问题，给出排查思路和解决命令，希望你能直接复制操作。

7.1 SSH 认证失败与权限拒绝

现象：执行ssh -T git@gitee.com时提示Permission denied (publickey)，或者 push 时报git@gitee.com: Permission denied (publickey)。

优先按以下顺序排查：

# 1. 查看本地是否有私钥文件 ls -l ~/.ssh/ # 2. 查看 SSH agent 是否加载了密钥 ssh-add -l # 3. 如果密钥文件存在但 agent 没有加载，手动加载 ssh-add ~/.ssh/id_ed25519 # 4. 使用详细模式测试，观察输出 ssh -vT git@gitee.com

如果~/.ssh下根本没有密钥文件，说明之前没有生成过，需要回到 3.2 节重新生成。另一个常见的隐藏坑是：系统里存在多个私钥文件，SSH 默认使用~/.ssh/id_rsa或id_ed25519，如果你用的密钥文件名不是默认名字，需要在~/.ssh/config里配置IdentityFile来指定。

7.2 Push 被拒绝：remote rejected

原因通常是分支保护规则。处理方式是用git fetch拉取最新，检查目标分支是否配置了保护，或者把当前分支推送到一个新的分支再发起 PR。还有一种情况是本地的分支和远程分支历史不一致，出现non-fast-forward的报错，这代表远端有本地没有的提交。解决办法是先拉取合并：

git pull origin main --rebase git push origin main

--rebase比默认的 merge 方式更适合个人开发分支，它会把本地提交“垫”到远端最新提交之上，避免产生无意义的合并提交。需要注意的是，rebase 会改写本地提交历史，在已经 push 过的公共分支上慎用。

7.3 中文文件名或内容乱码

在 Linux 下从 Gitee 克隆的仓库，如果遇到中文文件名显示成转义序列\345\274\240，可以这样设置：

git config --global core.quotepath false

这个配置让 Git 在输出文件名时不使用八进制转义，保持中文可读。内容乱码的情况通常是文件本身的编码问题，跟 Gitee 无关，但建议团队统一使用 UTF-8 编码，并在.gitattributes里声明：

* text=auto

7.4 大文件与仓库体积膨胀

如果仓库里需要存放大文件（比如二进制模型包、设计稿、视频素材），直接把文件提交进 Git 仓库会使得.git目录越来越大，每次 clone 都费时费力。Gitee 有专门的大文件存储功能，思路类似 Git LFS（Large File Storage），也就是把大文件的指针提交到仓库，而实际文件内容存到独立的存储服务中。在 Linux 上的使用方式：

git lfs install git lfs track "*.tar.gz" git add .gitattributes git add 文件路径 git commit -m "添加大文件" git push origin main

关键点是最一开始就先git lfs track，再添加文件，否则已经常规提交进历史的大文件不会自动转移。仓库膨胀之后，要清理历史记录会非常麻烦，所以我建议在项目启动第一天就约定大文件的存放策略。

7.5 常用问题速查表

8. Linux 服务器上的自动化部署实践

很多人在 Linux 下用 Gitee，终极目标是实现代码提交后服务器自动拉取、自动构建、自动重启服务。我用一个基于 WebHook 的完整例子来演示这个链路，这也算是对前文知识的一次串联。

8.1 用 Flask 写一个简单的 WebHook 接收端

假设你有台服务器，部署了一个简单的 Python Web 服务，目录是/opt/myapp，希望通过 Gitee 的 push 事件自动更新代码。先在服务器上写一个 Flask 服务：

# /opt/webhook/app.py from flask import Flask, request, jsonify import subprocess, hmac, hashlib, os app = Flask(__name__) # 这个 secret 要和 Gitee WebHook 配置中的 secret 保持一致 SECRET = "your-custom-secret" @app.route("/webhook", methods=["POST"]) def handle_webhook(): signature = request.headers.get("X-Gitee-Token", "") payload = request.get_data() # 简单校验自定义 token 字段，也可以按 Gitee 的签名规则校验 if signature != SECRET: return jsonify({"status": "forbidden"}), 403 data = request.get_json() branch = (data.get("ref") or "").replace("refs/heads/", "") repo_name = data.get("repository", {}).get("name", "") if branch == "main" and repo_name == "myapp": # 执行部署脚本，这里用 nohup 避免阻塞 HTTP 响应 subprocess.Popen(["/opt/myapp/deploy.sh"]) return jsonify({"status": "ok"}), 200 return jsonify({"status": "ignored"}), 200 if __name__ == "__main__": app.run(host="0.0.0.0", port=9000)

然后写部署脚本/opt/myapp/deploy.sh：

#!/bin/bash cd /opt/myapp git pull origin main pip install -r requirements.txt systemctl restart myapp

给脚本添加执行权限：chmod +x /opt/myapp/deploy.sh。

8.2 配置 Gitee WebHook 并测试

在 Gitee 仓库的管理页面找到 WebHook 配置项，填入 URLhttp://你的服务器IP:9000/webhook，Secret 设置成上面对应的your-custom-secret，事件按需勾选 push。保存之后，在本地随便提交一次并 push 到 main 分支，服务器会自动收到请求。检查 Flask 的日志确认请求进来了，再检查部署脚本是否执行，最终验证服务是否已经更新到最新代码。

这个流程上线后，你就不再需要每次手动 SSH 到服务器执行git pull了。配合前面讲的 Release 功能，甚至可以把编译产物通过 API 上传到 Gitee Release，然后 WebHook 触发服务器去下载产物并解压部署，实现完整的自动发布链路。

8.3 定时同步 Gitee 仓库到服务器

如果 WebHook 这种方式因为网络原因不稳定，退而求其次的方案是用 Linux 的 cron 定时任务定期拉取 Gitee 仓库。在crontab -e中添加：

*/5 * * * * cd /opt/myapp && git pull origin main >> /var/log/myapp-sync.log 2>&1

这个方案简单可靠，缺点是存在最长 5 分钟的延迟，不适合需要即时发布的场景。另外定时任务里必须注意 Git 命令在脚本中的权限问题，通常需要指定-C参数或者在脚本里先cd到仓库目录。

9. 一些最后想分享的操作习惯

讲完上面的所有流程，最后分享几个我踩过坑之后养成的操作习惯，算不上教程，但确实能帮你少走弯路。

第一个习惯是每次新装 Linux 系统后，第一时间把 Git 全局配置和 SSH 密钥配置好。不要等到真正要推代码时才想起来，到时候又是一轮找密钥、加公钥的折腾。配置文件的备份也很重要，我会把~/.ssh/config、~/.gitconfig纳入自己的 dotfiles 仓库管理，换机器时一条命令就能恢复环境。

第二个习惯是 commit 信息里尽量带上可追溯的编号。比如如果是某个需求或者 Bug 修复，在信息里带上项目管理系统的编号，例如fix: #123 登录接口超时问题。Gitee 的提交记录页面支持对 commit 的检索，编号信息能让后续排查问题定位变更时省很多力气。

第三个习惯是谨慎处理.gitignore。新手常常忽略它，等到把密钥文件、数据库配置、敏感日志都推上去了才后悔。我建议在项目最开始就配置好，之后再发现漏了什么东西，哪怕推错了，也要立即从远程仓库删除并清理历史，而不是简单提交一个新 commit 假装没发生。撤销提交历史的操作要非常熟练，但更重要的是预防。

第四个习惯是对大仓库的浅克隆要有敬畏心。在 Linux 服务器上部署时，我通常会考虑是否真的需要完整历史，如果只是运行代码，浅克隆加定时拉取是最高效的组合；但如果是需要基于历史做排查，浅克隆会带来麻烦。这种情况不要省。

我在实际使用 Gitee 的过程中，体会最深的一点是：工具本身不难，难的是把配置、权限、协作流程和自动化链路一次想清楚。很多坑其实在第一次配置时花五分钟就能避开，但大多数人都是等到 push 被拒绝、服务器更新错误、历史被污染之后才回头补课。希望这一篇能帮你把 Gitee 和 Linux 这套组合真正用顺，少走点弯路。