企业官网建设流程全解析

前几天群里有人问我一个“小问题”：怎么在远程服务器上搞 Git 仓库？他刚把开发环境从本地搬到服务器，代码拷来拷去，乱成一锅粥。接着他又补了一句：你之前不是说你主力 IDE 换成 Trae CN 了吗？那玩意连远程服务器方便吗？

这两个问题凑一块，其实一点都不“小”。我在服务器上折腾 Git 踩过的坑，零零散散够写好几篇。这篇干脆拆开揉碎讲清楚：远程服务器上的 Git 仓库到底怎么搭、怎么用，以及我现在主力用的 Trae CN 连接远程服务器做开发的真实体验。适合正在从本地开发往服务器开发迁移的人，也适合想找个顺手 AI IDE 连服务器干活的人。

1. 先把场景理顺：在远程服务器上搞 Git，你到底想干嘛

远程服务器上碰 Git，和本地开发完全是两种心智负担。本地你操作的都是自己的文件，乱了大不了重新 clone。服务器上不一样，它可能正跑着线上服务，你一个git pull没拉对，代码直接滚回一个钟头前。所以我建议动手前先想清楚：你到底属于哪类需求。

1.1 我见过最多的三种服务器 Git 需求

第一种，把服务器当代码集中托管点。团队小、不想搭 GitLab，就在一台有公网 IP 的服务器上建一个裸仓库，大家往里推代码。这种适合“服务器 = Git 服务器”的场景，和 GitHub 的角色一样，但完全自己掌控。

第二种，在服务器上拉取项目直接部署或者调试。生产环境或者测试服务器上要把最新代码跑起来，登录服务器后git clone、git pull，然后改配置、重启服务。

第三种，本地用 IDE 连到服务器上开发。你在服务器上建好仓库、拉好代码，人却在本地，用 Remote SSH 插件把远程文件夹当本地工程打开，改代码、跑 Git 操作、用 AI 辅助，全都在远程目录上完成。这也是我目前最主要的用法。

1.2 我推荐的服务器端 Git 工作流

如果项目部署到服务器，我一般走“本地改好，push 到仓库，服务器 pull 下来”的流程。这样服务器永远只保存“稳定可用”的代码，心理负担小很多。

但如果是调试服务器上的临时问题，尤其是要边看日志边改代码的场景，这套流程就太重了。这时候我会直接连上远程环境，在服务器上改完、用 Git 管理版本，确认没问题再同步回主仓库。

用 Trae CN 这类带 AI 的 IDE 连远程服务器，最大的好处是把第三种场景体验拉到了接近本地开发的水准，改代码的同时还能让 AI 帮忙解释报错、搜日志、改文件。这就是为什么我在标题里把“Git 仓库”和“Trae CN”放在一起讲——你连服务器的姿势变了，Git 的操作习惯也得跟着变。

2. 远程服务器上 Git 仓库的完整实操

2.1 服务器上还没有 Git？先装上

很多云服务器默认不带 Git。装一下很简单。

Debian/Ubuntu 系：

sudo apt update sudo apt install git -y

CentOS/RHEL 系：

sudo yum install git -y

装完先看版本：

git --version

这里有个新手必踩的坑：装完之后直接 commit 大概率会报Please tell me who you are。因为 Git 默认不知道你是谁。先配好用户名和邮箱：

git config --global user.name "Your Name" git config --global user.email "you@example.com"

如果你只想在某个仓库里用不同身份，去掉--global再执行一遍就行。这个配置会写入当前仓库的.git/config，适合一台服务器上多个项目用不同账号的场景。

2.2 从零初始化一个远程仓库：裸仓库方式

如果你准备把服务器当中央仓库，不要用git init，要用git init --bare。

普通仓库带工作区，你可以直接在里面改文件，但它不适合“所有人往这里推代码”。因为 Git 默认会拒绝往当前有工作区的分支上推送，而且多人共用一套工作区会互相污染。

裸仓库没有工作区，它只存 Git 历史，专业的事干专业的活。操作步骤：

ssh user@your-server mkdir -p /srv/git/myproject.git cd /srv/git/myproject.git git init --bare

本地机器上，给这个服务器加一个远程地址：

git remote add origin user@your-server:/srv/git/myproject.git git push -u origin main

第一次 push 可能需要密码。等你项目里有内容了，每个同事只要git clone user@your-server:/srv/git/myproject.git就能拉下来，再正常提交推送就行。

这里有个权限问题要提醒：/srv目录默认是 root 的，普通用户没写权限。我图省事，早年直接在/home/user/git/下建仓库，后来人多了才专门建了一个git系统用户，把仓库统一放在/home/git/repos/下，用git用户做接管。如果你只是自己用，放 home 目录完全没问题，省得整天跟权限搏斗。

2.3 从远程拉取已有项目：clone 和认证

更多情况下，你不是新建仓库，而是要把公司 GitLab、Gitea 或者 GitHub 上的项目拉到服务器上部署。

git clone git@gitlab.example.com:group/project.git

或者用 HTTPS 方式：

git clone https://gitlab.example.com/group/project.git

HTTPS 方式第一次会让你输账号密码。这里重点来了：现在企业 GitLab 基本都已经禁用密码登录，而是要求用 Personal Access Token。当你看到login failed. check api token or gitlab version. log in via git if the version...这种报错，八成就是 Token 没配对。

排查思路分两步：

第一，检查 git 版本。GitLab 版本更新后，对老 Git 客户端的兼容性会下降，尤其是 GitLab 14 以后，HTTP 智能协议有调整，老版本 git 可能直接甩这个报错。先升级 git：

# Ubuntu 下升级到较新的 git sudo add-apt-repository ppa:git-core/ppa sudo apt update sudo apt install git

第二，检查 Token 权限。生成 Token 时如果只勾了read_repository，那clone能成，push就会被拒。如果报错是 403 或者GitLab: You are not allowed to push code to this project，去 GitLab 设置里把 Token 权限勾上write_repository，再重新试。

我的建议是，如果服务器上只跑一个项目，直接用 SSH key 方式最省心，也就是下一步要讲的免密推送。

2.4 SSH 免密配置：一劳永逸的推送姿势

每次 push 都输账号密码真的很折磨人，尤其在生产服务器上频繁拉代码的时候。SSH key 免密是必须配的，步骤很简单：

在本地（或者你要推代码的机器上）生成密钥：

ssh-keygen -t ed25519 -C "your_email@example.com"

一路回车，默认生成在~/.ssh/id_ed25519.pub。

把公钥安装到服务器：

ssh-copy-id user@your-server

如果机器上没有ssh-copy-id，也可以手动：

cat ~/.ssh/id_ed25519.pub | ssh user@your-server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

然后把远程地址从 HTTPS 改成 SSH：

git remote set-url origin user@your-server:/srv/git/myproject.git

这里有个权限细节很关键：authorized_keys文件权限一定要是 600（仅 owner 可读写），~/.ssh目录要是 700。否则 SSH 会出于安全考虑直接忽略这个文件，表现就是“密钥明明加了还是让你输密码”。我至少被这个问题坑过三次。

如果你手上服务器多，建议在~/.ssh/config里配别名，比如：

Host my-server HostName 123.45.67.89 User ubuntu IdentityFile ~/.ssh/id_ed25519 Port 22

配完之后，clone 地址可以直接写成git clone my-server:/srv/git/myproject.git，又短又清晰。

3. 用 Trae CN 连远程服务器开发，体验怎么样

3.1 为什么我会把主力 IDE 从 VSCode 换成 Trae CN

我之前的日常是 VSCode 加一堆插件：Remote SSH、GitLens、通义灵码、Git Graph……插件越多，启动越慢，还经常遇到版本冲突。

Trae CN 本质上是基于 VSCode 的，插件生态完全通用，快捷键、界面布局几乎照搬。换句话说，我从 VSCode 迁过来基本零成本。但它把 AI 能力做成了内置的，不用再折腾插件配置，打开就能用，这一点很戳我。

另外在远程开发这个场景上，它继承了 VSCode Remote SSH 的能力，同时把 AI 功能和远程目录做得很贴合。现在我做服务器端调试，基本就是连上远程，让 AI 帮我解释日志报错，再顺手改几行代码。

3.2 从安装到连上远程服务器的完整步骤

第一步，下载安装 Trae CN。国内直接去官方渠道下载，装完用手机号或者邮箱登录。

第二步，安装 Remote-SSH 插件。虽然名字里带 VSCode，但这个插件在 Trae 的插件市场里也能搜到，直接装就行。

第三步，配置 SSH Config。在 Trae 里按Ctrl+Shift+P，输入Remote-SSH: Open SSH Configuration File，编辑你的~/.ssh/config，格式跟 VSCode 里完全一样。

第四步，连接远程服务器。Ctrl+Shift+P输入Remote-SSH: Connect to Host，选一个上面配置好的别名。第一次连会往服务器上安装服务端组件，等一会就好。

第五步，打开远程文件夹。连接成功后，菜单栏的“文件”里选择“打开文件夹”，输入远程服务器上的项目路径，比如/home/user/myproject，回车等它加载完。

装完这步你发现，左下角变成了 “SSH: my-server”，这时候左侧的资源管理器、源代码管理、终端，全都是远程的。你在编辑器里改的文件直接写进服务器，终端里执行git status也在远程目录下执行。

3.3 AI 在远程开发中的实际表现，以及接入 DeepSeek 的玩法

我平时用得最多的三个场景：让 AI 解释报错、让 AI 生成代码片段、用 Agent 模式直接改文件。

解释报错这块，Trae CN 的上下文感知做得不错。在远程终端里执行完一条命令，如果报错了，复制下来粘到 AI 对话框，它基本能结合当前项目文件和远程环境给出靠谱答案，不用像以前那样自己满世界搜。

生成代码片段就更直接了，比如在某个 py 或者 js 文件里让 AI 写个脚本，它会基于当前工作区的文件风格自动适配。远程开发时唯一要注意的是权限确认——Trae 的文件编辑和命令执行都需要授权，别嫌弹窗麻烦，这就是个保障机制。

关于接入 DeepSeek，Trae CN 的设置里可以选择和配置不同的模型服务。如果你自己申请了 DeepSeek 的 API Key，可以在模型配置里把它填进去，走自定义模型通道。这样在不用官方内置模型的时候，也能用上 DeepSeek 的推理能力。

实际体感上，DeepSeek 在中文理解和代码生成质量上都挺能打，尤其在解释项目逻辑和写工具脚本这类任务上。不过要注意 API 调用会消耗额度，远程开发时如果让 AI 频繁读文件，消耗速度比本地快，所以别让 AI 做大量无意义的全局扫描。

3.4 Trae 的积分、兑换码和关掉自动更新的折腾

Trae CN 的 AI 功能走积分制。我这段时间用下来的感觉是：日常写代码、问问题完全够用，但如果频繁跑 Agent 模式，耗得很快。

积分来源主要有三个渠道：每天登录送一部分、做官方任务和参与活动能拿一部分、邀请好友注册是拿大额积分的主要途径。至于网上流传的“Trae 积分兑换码”，我的建议是别买。那些大部分是诱导关注的营销钩子，真到手也未必靠谱。想要积分就老实做官方任务和邀请，稳一点。

自动更新这事我必须多说一句。有一次 Trae 后台自动更新完，我装的一个私有插件直接失效了，远程环境也重新加载了半天。之后我就把自动更新关了。方法是在设置里搜索“更新”或“update”，把“自动更新”和“后台自动下载更新包”都关掉。如果你用的是公司电脑，还可以顺带关掉“自动检查更新”，彻底告别突如其来的重启。

4. 常见问题排查实录与避坑清单

这一节我按三类来整理，都是我在服务器开发和 Trae CN 使用过程中真实踩过的坑，每个都给你附上排查思路。

4.1 远程连接类问题

连接远程服务器常见报错是超时。SSH 默认 22 端口，很多云厂商的安全组默认不开。排查套路：先ping 服务器IP，通了说明网络通；再telnet 服务器IP 22，通不了看安全组和防火墙。

ssh -v user@your-server

加-v能打印详细连接日志，卡在哪一步一目了然。如果卡在expecting SSH2_MSG_KEXINIT，一般是被防火墙拦了或者 SSH 端口不对。

Trae 或 VSCode 连上去之后反复要密码，很可能是密钥没生效。检查~/.ssh/authorized_keys里公钥是否正确、权限是否为 600，再确认本地~/.ssh/config里没有写死PasswordAuthentication。

还有一个 Windows 用户容易遇到的问题：用 PowerShell 的irm命令下载执行脚本时报irm : 无法连接到远程服务器。这通常不是网络不通，而是 PowerShell 默认的 TLS 版本太旧，或者访问的地址在系统代理策略里没放行。升级 PowerShell 到 7.x，或者在当前会话里设置[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12就能解决。如果你是在安装 Git 或配置环境时踩到这个报错，多半是下载脚本的地址不可达导致，换官方渠道下载安装包更稳。

4.2 Git 操作类问题

服务器上git pull最常见的报错是这个：

error: Your local changes to the following files would be overwritten by merge

意思是本地有未提交的修改和远程冲突了。正常思路是保留本地修改，先暂存再拉取：

git stash git pull git stash pop

如果冲突文件就是不要的，直接丢弃：

git checkout -- <file>

另一种高发问题：服务器上所有文件都显示 modified，但内容没变。这是 Linux 下 Git 检测到文件权限位变化导致的。解决办法：

git config core.fileMode false

也可以全局关掉：git config --global core.fileMode false，以后这个机器上就不会再因为 chmod 导致文件状态误报。

中文文件名在git status里显示成一串\xxx乱码，是 Git 默认转义导致的。记得设一下：

git config core.quotepath false

这也是 VSCode/Trae 内置 Git 插件在每次操作前会自动加的那些-c core.quotepath=false参数的作用。理解了这个参数，你在服务器上手工操作时就不会再疑惑为什么文件名显示成乱码了。

还有一个登录相关：login failed. check api token or gitlab version。如果你是拉 GitLab 项目遇到，按我前面说的先升级 Git、再检查 Token 权限，基本能定位。如果是 GitLab 版本过老而客户端 Git 太新，那就看 API 兼容提示，考虑升级 GitLab。

4.3 Trae CN 自己的坑

Trae CN 在远程开发里最大的问题我觉得是自动更新。之前更新完某个版本后，远程环境的 VSCode Server 组件和本地版本不匹配，导致连上服务器后一直转圈。关掉自动更新后，这个问题基本没再出现过。

另外，Agent 模式在远程目录里跑，权限弹窗频率比本地高很多。这是正常的，因为有大量文件修改和命令执行。如果觉得弹窗太频繁，可以在设置里把某个目录加入信任区，降低授权频率。

还有内存占用。Trae 本身占用就比 VSCode 高一些，远程开发时本地和远程两边都要跑组件，在配置低的云服务器上，建议把远程端的 VSCode Server 相关配置调低，或者不要同时开太多大文件。

5. 和 CodeBuddy 等同类 AI IDE 对比后，我的选择建议

既然热词里有人问“Trae CN 和 CodeBuddy 怎么选”，我就把这段时间的对比观察写一下。

先说结论：两款都是国内能用、中文友好的 AI IDE，但侧重不太一样。Trae CN 的优势在于它从诞生起就是一个“AI 原生的 VSCode 改版”，界面、快捷键、插件生态和 VSCode 几乎无缝衔接，对从 VSCode 过来的开发者最友好。CodeBuddy 的优势在于腾讯生态整合，在某些企业内网场景下有独特优势。

我拉了一张对比表，方便你根据自己的场景判断：

我个人的选择标准就三条：插件兼容性、AI 在远程环境下的阅读能力、以及不想反复折腾更新。

如果你平时 VSCode 已经装了一大堆插件，换 IDE 最怕的就是插件不兼容，那 Trae CN 基本是无痛的。如果你在公司内网，项目协作强依赖腾讯系工具链，CodeBuddy 也许更合适。至于 Cursor 这类海外工具，国内使用体验受网络环境影响，企业生产环境里我还是更推荐国内产品。

6. 最后再分享一个小习惯

我开始用 Trae CN 连远程服务器开发后，最大的变化是：敢在线上环境动代码了。以前每次改生产服务器的代码都小心翼翼，改一个字符都恨不得先备份三份。现在有了 Git 仓库兜底，改了不合适就git checkout .，配合 AI 快速定位问题，效率确实上来了。

但我也有个底线：生产服务器上，git push永远从本地发起，服务器上只做git pull和临时调试修改，调试完发现有价值的改动，我会同步回本地再统一提交。远程环境里的代码，我默认它不是“最终版本”，只是“临时状态”。这也算是在效率和数据安全之间找的一个平衡。

最后分享一个小技巧：如果你在服务器上用 HTTPS 方式拉私有仓库，又不想每次输 Token，先执行一次

git config --global credential.helper store

然后在第一次 push 时输入一次 Token，之后 Git 会存到~/.git-credentials里。不过要注意这个文件是明文存储的，多人的服务器上建议不要用，或者配合 ssh-key 方案代替。我在个人测试机上用过一段时间，后来发现风险大于便利，还是回归 SSH key 了。

Trae CN 现在还在快速迭代，远程开发体验已经比早期版本顺滑很多，也时不时会冒出一些小问题。如果你准备把它当成日常主力工具，我的建议是：先在测试项目里用两周，把插件、密钥、工作流都摸顺了，再切到生产项目上，这样踩坑成本最低。