Linux 下 Gitee 代码托管实战：Git、SSH 密钥与分支管理

1. 先把话说在前面为什么 Linux 用户更该把 Gitee 当成主力代码仓我在 Linux 上写代码的年头不算短最开始那几年特别迷信图形化客户端觉得点几下鼠标就能提交多省事。直到有一次在服务器上改了一个部署脚本本地没装任何 GUI 环境只有 SSH 终端那一刻才意识到在 Linux 上真正靠得住的永远是指令行那一套。而 Gitee 作为国内访问速度相对稳定的代码托管平台配合 Linux 终端里的 git 命令是我目前最顺手的一套组合——不需要折腾网络push 上去几秒钟就看到结果这对天天要提交代码的人来说体感差别很大。这篇内容讲的就是这套组合怎么落地从装 git、配 SSH 密钥、建仓库、把本地已经写好的代码推上去到日常的拉取、分支、冲突处理再到 Linux 环境下几个特别容易踩的坑最后顺带聊一下许可证选择、静态托管和仓库批量清理这类建完仓库之后才会遇到的问题。不管你是刚装上 Linux 想学 gitee 使用教程还是已经用过一段时间但总是被各种报错卡住下面这些内容都能直接照着敲。我先把一个结论摆在这儿Linux 下用 Gitee核心就三件事——身份对得上、密钥认得清、路径别搞错。这三件事理顺了剩下 90% 的操作都是几条固定命令的排列组合。1.1 先装 git但别闭着眼睛apt install很多人第一步就埋了雷。不同发行版自带的 git 版本差异很大尤其是某些长期支持版本的系统仓库里的 git 可能还是好几年前的老版本git switch、git restore这些相对新的子命令直接不存在或者行为跟文档对不上。我一般会先看一眼当前版本。git --version如果输出是 2.23 以下建议想办法升级。下面是几个主流发行版的安装与升级方式按你手头的系统选发行版安装命令备注Debian / Ubuntusudo apt update sudo apt install git老版本系统建议加官方 PPA 升级CentOS / RHEL 7sudo yum install git自带版本偏旧可考虑源码编译CentOS / RHEL 8sudo dnf install git版本相对新够用Arch / Manjarosudo pacman -S git版本一直很新openSUSEsudo zypper install git用zypper up git升级源码编译./configure make sudo make install适合内网机器、离线环境源码编译这条路我走过几次主要是给一些不能连外网的机器用。步骤不复杂但有个细节要注意编译前先确认curl-devel、expat-devel、zlib-devel这几个开发包装好了否则 git 编译出来不支持 https 协议后面 clone 的时候会报 unable to find remote helper for https这个错我第一次遇到时排查了快一个小时。装完之后再跑一次git --version确认顺便配置一下自动补全Linux 下敲命令会舒服很多。# 下载 git 的补全脚本以 bash 为例 curl -o ~/.git-completion.bash \ https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.bash # 写进 shell 配置 echo source ~/.git-completion.bash ~/.bashrc source ~/.bashrc这一步不是必须的但你的分支名一旦长起来git checkout feat/order-export-2024这种命令靠手打会很崩溃自动补全能省下大量时间。1.2 身份配置user.name和user.email到底影响什么装完 git 第一件事是配全局身份命令就两行git config --global user.name 你的名字 git config --global user.email 你的邮箱看起来简单但这里有两个很常见的误解我觉得有必要说清楚。第一个误解以为这里的邮箱必须和 Gitee 账号的注册邮箱一致。实际上不是必须的但强烈建议一致。因为 Gitee 的提交记录是靠邮箱去关联账号的如果你的user.email跟账号绑定的邮箱对不上你 push 上去的提交头像和用户名会显示不出来看起来像是一个陌生人在你的仓库里提交代码。团队协作的时候这个现象会让人很困惑。第二个误解以为配置一次就够了。全局配置只是默认值如果你在公司项目和个人项目之间切换可能需要在不同仓库里配不同的身份这时候用去掉--global的版本在仓库目录里执行cd ~/projects/work-project git config user.name 公司要求的名字 git config user.email 公司邮箱验证配置是否生效可以直接列出来看git config --global --list git config --local --list我个人的习惯是全局配一个个人身份凡是参与团队协作的仓库进目录先本地覆盖一次。这个动作只要十几秒但能避免后面提交记录乱成一锅粥还得改历史。注意如果你已经提交了几次才发现邮箱配错历史提交是改不掉显示效果的除非改历史并强推所以这一步最好在第一次 push 之前就确认好。2. SSH 密钥Linux 下连 Gitee 最不容易出岔子的一条路在 Linux 上连 Gitee有两种方式HTTPS 和 SSH。HTTPS 每次推送都可能要你输账号密码而 SSH 配好之后基本就是一劳永逸所以我默认推荐所有 Linux 用户走 SSH。这一章把密钥这条链路完整拆开包括生成、贴公钥、验证、以及多密钥共存的情况。2.1ssh-keygen那几行交互到底在问什么生成密钥的命令是ssh-keygen -t rsa -b 4096 -C 你的邮箱执行之后会连续问你几个问题很多人第一次看到是懵的。第一个问题Enter file in which to save the key (/home/you/.ssh/id_rsa):它问的是密钥保存位置。如果你只有一套密钥直接回车用默认路径就行也就是~/.ssh/id_rsa和~/.ssh/id_rsa.pub。如果你想给 Gitee 单独生成一套比如同时还在用其他平台这里要输入一个自定义路径例如/home/you/.ssh/gitee_id_rsa第二个问题Enter passphrase (empty for no passphrase):这是给私钥加一层口令保护。加了之后每次使用密钥都要输入口令安全性更高但日常高频推送会很烦。我的做法是加一个口令然后用ssh-agent缓存起来当天只需要输一次。如果图省事直接回车留空也行但要知道私钥文件就相当于你的身份证一旦泄露别人就能以你的身份推送代码。生成完之后确认一下文件ls -l ~/.ssh/ # 应该能看到 gitee_id_rsa 和 gitee_id_rsa.pub # 权限应该是 600私钥和 644公钥 # 如果不对手动改一下 chmod 600 ~/.ssh/gitee_id_rsa chmod 644 ~/.ssh/gitee_id_rsa.pub权限这个事特别重要。SSH 对私钥文件权限非常敏感如果权限过宽比如 777它会直接拒绝使用这个密钥报错信息是 Permissions 0777 for xxx are too open。这个报错看起来吓人其实解决办法就是两行 chmod。2.2 公钥贴到 Gitee 的正确位置拿到公钥内容cat ~/.ssh/gitee_id_rsa.pub输出的是一长串以ssh-rsa开头、以你的邮箱结尾的字符。注意这里要复制的是.pub结尾的公钥不是私钥我见过不少人复制错文件然后在平台上怎么都验证不通过最后发现是把私钥贴上去了——这个操作在安全上等同于把家门钥匙塞进别人信箱是绝对不能做的。登录 Gitee 之后进个人设置里的 SSH 公钥管理页面新增一个公钥把内容粘贴进去标题随便起一个能认出来的名字比如 公司台式机-ubuntu保存。然后回来验证ssh -T gitgitee.com第一次连接会提示是否信任这个主机的指纹输入yes。看到类似Hi 你的用户名! Youve successfully authenticated...就说明成功了。如果你用的是自定义路径的密钥直接ssh -T是不行的它默认只会找~/.ssh/id_rsa。需要在~/.ssh/config里写一段配置# ~/.ssh/config Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/gitee_id_rsa PreferredAuthentications publickey配好之后再跑ssh -T gitgitee.com就会自动用指定的密钥了。这个 config 文件还有一个好处如果你同时要用多个平台可以给每个配一段互不干扰。2.3 HTTPS 和 SSH 的取舍虽然我推荐 SSH但也不能说 HTTPS 就一无是处。实际选型上两种方式各有场景对比项SSHHTTPS认证方式密钥对账号密码或个人访问令牌是否需要重复输入配好后不需要默认每次都要可用 credential helper 缓存端口22公司网络可能封禁443代理环境配置相对麻烦跟随系统代理更自然推荐场景个人开发机、长期使用临时环境、CI 机器、22 端口被封的场合如果 22 端口确实被限制SSH 也不是没救Gitee 支持通过 443 端口的 SSH 连接配置里加上端口即可。但这条路我一般只在实在没办法的时候才走日常还是老老实实用默认配置。2.4 多套密钥共存时最容易搞混的地方很多人发展到后面手头会有好几套密钥公司的、个人的、服务器的。这时候~/.ssh/config就是核心工具。一个常见的配置长这样Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/gitee_id_rsa Host gitee-work HostName gitee.com User git IdentityFile ~/.ssh/gitee_work_rsa注意第二个块的Host写的是别名gitee-work而不是域名这样在用的时候就要把远程地址改成对应的别名git remote add origin gitgitee-work:公司命名空间/仓库名.git验证也是用别名ssh -T gitgitee-work我踩过一次坑两个块都写了Host gitee.com结果 git 只认第一个块里的密钥公司仓库怎么推都是权限拒绝。后来才搞明白同名 Host 后面的会被前面的覆盖掉要用别名区分。提示ssh -vT gitgitee.com这个命令会打印详细的握手过程能看到它到底用了哪个私钥文件。密钥问题排查不出来的时候先跑这个。3. 从零到推上去把本地已写好的代码放进 Gitee 的完整链路这一章讲实操最多的部分。很多人的场景是本地已经有一堆写好的代码文件想放到 Gitee 上。这个过程分两头Gitee 那边要建仓库本地这边要初始化并连接。我把两头都拆细。3.1 Gitee 侧建仓库时那几个勾选项新建仓库的界面看着简单但有几个选项会影响后面顺不顺。仓库名称建议用英文、小写、连字符比如order-export-tool。用中文名虽然在网页上看得懂但生成出来的 clone 地址会带 URL 编码复制到终端里奇奇怪怪还可能在某些工具里识别不了。是否开源开源就是所有人可见私有就是只有你和被邀请的人可见。个人项目的建议是只要里面没有密钥、账号、公司内部信息开源问题不大一旦涉及配置文件里带密码先私有等清理干净再考虑公开。初始化选项是否自动生成 README、.gitignore、开源许可证这里有个非常关键的注意事项。如果你本地已经写好了代码要推上去这三个选框建议全部不勾。因为一旦勾了仓库初始化时就先有了一个提交你本地推的时候会因为历史不一致被拒绝还得先 pull 合并凭空多出一堆麻烦。空仓库最适合承接本地已有代码。3.2 本地初始化到首次推送的完整命令序列假设你本地代码在~/projects/order-export-tool仓库是空的完整流程如下cd ~/projects/order-export-tool # 1. 初始化本地仓库 git init # 2. 先写 .gitignore这一步别省 cat .gitignore EOF # 编译产物 *.o *.so *.class target/ build/ dist/ # 依赖目录 node_modules/ venv/ __pycache__/ # 配置与密钥绝对不能提交 .env *.pem *.key config/local.yml # IDE 配置 .idea/ .vscode/ *.swp # 系统文件 .DS_Store Thumbs.db EOF # 3. 把当前所有文件加入暂存区 git add . # 4. 检查到底会提交哪些文件这一步很关键 git status # 5. 提交 git commit -m chore: 项目初始化 # 6. 关联远程仓库 git remote add origin gitgitee.com:你的用户名/order-export-tool.git # 7. 推送并建立上游跟踪 git push -u origin master这里面有两个地方我要重点提醒。第一git add .之前一定要写.gitignore。我见过太多次一个人兴冲冲地git add .然后git status里赫然列着node_modules下的几千个文件或者.env里的数据库密码。文件一旦提交进历史即使后面删掉历史记录里还留着想彻底清除就得用filter-branch或者filter-repo改历史非常麻烦。所以顺序一定是先写忽略规则再加文件。第二推送前用git status和git diff --cached --stat看一眼。前者看有哪些新文件会被提交后者看已暂存文件的改动统计git diff --cached --stat输出会是类似下面这样一眼就能看出有没有不该进去的东西.gitignore | 25 src/main.py | 210 src/utils.py | 88 README.md | 34 4 files changed, 357 insertions()第三关于分支名。老版本 git 默认分支叫master新版可以配置成main。Gitee 建仓时也会让你选默认分支名。如果你的本地默认分支和远程不一致push 的时候会提示远程分支不存在或者推上去之后默认分支没变。我的建议是本地和远程保持一致在git init之后就确认一下# 查看当前分支名 git branch --show-current # 如果需要重命名在首次提交前执行 git branch -m main3.3 本地已经是个 git 仓库只是要换远程地址这是另一种常见场景代码本来在别的平台或者别的地址现在想迁到 Gitee。这时候不用重新 init改远程地址就行cd ~/projects/existing-repo # 查看当前远程地址 git remote -v # 改成 Gitee 的地址 git remote set-url origin gitgitee.com:你的用户名/新仓库.git # 或者删掉重新加 git remote remove origin git remote add origin gitgitee.com:你的用户名/新仓库.git # 推送所有分支 git push -u origin --all # 如果要连标签一起推 git push origin --tags--all和--tags这两个参数经常被漏掉。只推当前分支的话其他分支和所有标签都不会过去等你换台机器 clone 下来发现少东西还得回头补推。3.4 首次推送最常撞上的几个报错我把第一次推送时高频出现的报错整理成一张表配上官方的排查方向报错信息关键词大概率原因处理方向Permission denied (publickey)密钥没配对、公钥没贴、用了错的 Hostssh -vT看用了哪个私钥remote: Incorrect username or password用了 HTTPS 地址但密码错换成 SSH 地址或用令牌failed to push some refs远程有本地没有的提交先git pull --rebasesrc refspec master does not match any本地根本没提交确认git log有记录Repository not found仓库地址拼错或没权限复制界面上的地址对照Could not resolve hostname域名解析问题或代理配置异常检查/etc/resolv.conf与网络设置其中failed to push some refs是我见过最多的。它出现的根本原因是远程仓库里有一个初始提交比如建仓时勾了 README而你的本地历史里没有这个提交两个历史没有共同祖先。解决办法有两个要么git pull --rebase origin master把远程的提交先接过来要么确认远程内容是空的之后强推。强推要谨慎git push -f会覆盖远程历史如果那是别人也在用的仓库后果很严重。4. 日常真正高频的那几条命令与分支习惯仓库建好只是开始真正天天用的是后面这套。这一章讲的是把 Gitee 用顺之后的日常操作包括分支策略、拉取方式的选择、冲突处理以及.gitignore在仓库运行起来之后怎么继续维护。4.1 一个人开发也别一直在主干上裸奔我早期写个人项目就是一路在master上提交觉得反正只有自己看。后来有一次改一个功能改到一半突然线上有个紧急问题要修才发现工作区里全是半成品代码根本没法干净地切出去。从那之后我养成了习惯哪怕是单人项目也至少保持主干可用功能改动开分支。# 从主干开新分支做功能 git switch -c feat/user-login # 开发、提交若干次 git add . git commit -m feat: 用户登录接口 # 推送到 Gitee git push -u origin feat/user-login # 功能完成切回主干合并 git switch master git merge --no-ff feat/user-login git push origin master # 删掉已合并的分支 git branch -d feat/user-login git push origin --delete feat/user-login--no-ff这个参数的意思是禁用快进合并强制生成一个合并提交。好处是历史记录里能清楚看到这里合并过一个功能分支而不是所有提交平铺成一条线。团队协作时这个习惯特别重要方便回溯。分支命名上我用的是比较土但好记的一套feat/xxx新功能、fix/xxx修 bug、chore/xxx杂活、hotfix/xxx紧急修复。不用太讲究规范关键是能一眼看懂。4.2pull --rebase还是merge这个选择挺重要从远程拉取代码默认行为是 merge也就是会生成一个合并提交。如果你的本地有几个提交还没推远程也有别人的提交默认拉取之后就变成这样* merge commit |\ | * 远程的提交 * | 你本地的提交 |/ * 共同祖先看着有点乱。用rebase的话会把你本地的提交摘下来接到远程最新提交的后面历史变成一条干净的直线git pull --rebase origin master我个人的配置是让 pull 默认走 rebasegit config --global pull.rebase true但这个配置有个前提你本地的提交还没推送到远程。如果已经推上去了rebase 会重写提交 ID导致本地和远程历史分叉下次推送又要处理冲突。所以稳妥的判断标准是没推的用 rebase推过的用 merge。4.3 冲突发生之后的处理顺序冲突在团队协作里是躲不掉的。Gitee 网页端解决冲突的能力有限我建议一律拉到本地解决。流程是这样# 1. 拉取让冲突暴露出来 git pull --rebase origin master # 2. 看哪些文件冲突了 git status # 输出里会有 both modified: xxx # 3. 打开冲突文件会看到这样的标记 # HEAD # 你本地的代码 # # 远程的代码 # 远程提交 # 4. 手工编辑决定保留哪一段删掉标记符 # 5. 标记为已解决 git add 冲突文件 # 6. rebase 模式下继续 git rebase --continue # 如果是 merge 模式直接提交 git commit处理冲突时有两个实用技巧。一是用git checkout --ours 文件或--theirs 文件直接选择保留某一方的完整版本适合整个文件取舍的情况。二是装一个合并工具git mergetool可以调起来图形化对比比手工看标记符舒服得多。提示如果 rebase 过程中彻底乱了git rebase --abort可以一键回到 rebase 之前的状态不用慌。4.4.gitignore是活的要跟着项目长很多人建仓时写了一份.gitignore就再也没动过。实际上项目一演进新的临时文件、新的构建目录、新的本地配置会不断冒出来。我发现这类问题的信号通常是git status里出现一堆不认识的文件。修改.gitignore之后对已经跟踪的文件是不生效的。比如你之前不小心把build/提交上去了后来加进忽略规则git 依然会跟踪里面已有的文件。这时候要先把它们从索引里移除# 从索引移除但保留本地文件 git rm -r --cached build/ # 提交这个变更 git commit -m chore: 移除构建目录的跟踪--cached这个参数非常关键没有它的话git rm -r build/会把你本地的构建产物也一并删掉。我第一次用的时候就是忘了加白白重新编译了一遍。5. Linux 环境下特有的几个坑跟 Windows 用户遇到的不太一样这一章讲的是 Linux 用户在使用 Gitee 过程中会碰到、但 Windows 用户不太会碰到的几类问题。这些坑我在不同机器上反复遇到过集中写出来遇到的时候能快速定位。5.1 换行符CRLF 和 LF 的隐形战争这是一个跨平台协作时的经典问题。Windows 用 CRLF 作为换行符Linux 用 LF。如果团队里有人用 Windows 有人用 Linux换行符没有统一git 会认为整个文件都被改了。# 在 Linux 上配置为提交时转为 LF检出时保持 LF git config --global core.autocrlf input # 查看当前配置 git config --global core.autocrlfinput的含义是提交的时候把 CRLF 转成 LF检出的时候不做转换。这样仓库里统一是 LFLinux 本地文件也是 LF干净。更好的做法是在项目根目录放一个.gitattributes文件把规则固化在仓库里* textauto eollf *.sh text eollf *.bat text eolcrlf *.png binary *.jpg binary这样不管谁 clone 下来规则都一致不依赖个人电脑上的配置。.sh脚本文件一定要指定eollf因为脚本里混进 CRLF 之后Linux 上执行会报bad interpreter: No such file or directory这个错误信息极其误导人实际上就是多了个隐藏的\r。5.2 权限位变化引起的满屏 mode changeLinux 下每个文件都有权限位644、755 之类。如果你换了台机器或者用 U 盘拷过文件权限可能就变了。这时候git status会显示一堆old mode 100644 new mode 100755文件名后面标着mode change看着像是文件内容改了其实只是权限位。处理方式有两种如果这些权限变化是有意义的比如脚本需要执行权限那就正常提交如果只是无意义的波动可以告诉 git 忽略权限变化git config core.filemode false我一般会在挂载的文件系统比如某些虚拟机共享目录、网络盘里做这个配置因为这类文件系统的权限位经常不正常。5.3 大文件与推送被拒Gitee 对单文件大小有限制超过限制的提交会被拒绝。常见触发场景是不小心把打包好的二进制、模型文件、数据库导出文件加进提交了。排查方式是找出仓库里最大的几个文件# 列出当前仓库中最大的 10 个文件 git ls-files | xargs -I {} du -h {} 2/dev/null | sort -rh | head -n 10找到之后如果文件还没提交加进.gitignore如果已经提交了但还没推用git reset撤回这次提交把文件从暂存区拿掉重新提交如果已经推送上去就得改历史了这条路比较重能用其他方式解决就别动历史。如果确实需要管理大文件可以考虑 Git LFS不过个人项目里我一般建议直接把大文件放到别的存储方式里仓库只放代码。5.4 中文文件名与编码问题Linux 环境下如果系统的 locale 没配好中文文件名可能显示成乱码提交之后在 Gitee 网页上看也是这样。先检查一下locale确认输出里有UTF-8比如LANGzh_CN.UTF-8。如果全是POSIX或者C那中文基本会出问题。临时调整export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8要永久生效就写进~/.bashrc或/etc/locale.conf。另外 git 本身有个core.quotepath配置默认值会让中文文件名在命令输出里显示成\344\270\255这种转义形式。改成 false 就能正常显示git config --global core.quotepath false这个配置不影响文件本身只是让git status的输出好读一些建议所有人都加上。5.5 时间不同步导致的连接异常这个坑比较隐蔽。有些虚拟机或者嵌入式设备开机后系统时间不对可能是几年前的时间。这时候执行 git 操作可能会报 SSL 证书相关的错误比如证书尚未生效或者已过期。# 查看当前系统时间 date # 同步网络时间 sudo ntpdate ntp.aliyun.com # 或者用 systemd 的服务 sudo timedatectl set-ntp true时间对了之后再试问题往往就消失了。这个现象我第一次遇到时完全没往时间上想排查了半天网络最后发现是虚拟机快照恢复后时间没同步。6. 仓库建起来之后才会用到的那几件事到这一章基础操作已经能跑通了。剩下这几件事是仓库运行一段时间之后必然会碰到的开源许可证选哪个、静态页面怎么托管、仓库多了怎么批量清理。6.1 开源许可证怎么选才不吃亏这是很多人建公开仓库时最纠结的一步。我用一张表把常见的几个许可证的差别列出来方便对照许可证允许商用允许闭源使用是否要求衍生作品开源典型适用场景MIT是是否工具库、示例代码、个人项目Apache-2.0是是否但需保留声明与变更说明企业级开源项目、带专利考量的项目BSD-3-Clause是是否与 MIT 类似多一条禁止背书条款GPL-3.0是否是强调开源的完整传递性LGPL-3.0是是动态链接情况下部分库类项目希望被闭源软件使用MulanPSL-2.0是是否国内项目常用的宽松许可选择逻辑我一般这么走想让别人随便用就选 MIT想让别人用但要保留署名和专利保护选 Apache-2.0希望衍生代码也必须开源选 GPL 系。MulanPSL-2.0 是国内主导的一个宽松许可如果项目主要面向国内使用者用这个也没问题。建仓时如果忘了选后面也可以手工加上在仓库根目录放一个LICENSE文件内容填对应许可证的全文然后在 README 里注明即可。Gitee 界面上通常也会识别出来并显示许可证标签。6.2 Gitee Pages 静态托管能做什么、限制在哪Gitee Pages 可以把仓库里的静态文件直接发布成一个可访问的网页适合放文档站、项目主页、纯前端页面。基本流程是仓库里准备好静态文件一个index.html加上相关资源在仓库服务里找到 Pages 相关入口选择分支和目录点击部署。有几点必须提前知道这是静态托管不能跑后端代码。HTML、CSS、JS、图片这些没问题需要服务端逻辑的功能它做不了。部署之后更新代码不会自动生效需要重新点一次部署。写脚本自动化的做法通常是调用对应的接口但接口的可用性会随平台政策调整用之前先确认当前状态。服务模式与配额以平台当前公示为准不同账号类型能用的功能不一样动手之前先看清楚说明别照着几年前的教程一步步做最后卡在权限上。对于纯前端项目我一般的工作流是本地开发调试好推到 Gitee触发一次部署然后访问生成的地址确认效果。这个流程比自己在服务器上配 nginx 省事得多适合展示型项目。6.3 仓库太多的时候怎么批量处理用久了之后仓库数量会失控。我有一段时间为了测试各种东西建了几十个临时仓库一个个手点删除实在受不了。这种情况可以借助平台提供的接口批量处理。大致的思路是先在账号设置里生成一个访问令牌然后通过接口列出自己的全部仓库筛选出要处理的那些再逐个调用删除或归档接口。import requests TOKEN 你的访问令牌 HEADERS {Content-Type: application/json} # 列出当前用户的所有仓库 def list_repos(page1, per_page100): url https://gitee.com/api/v5/user/repos params {access_token: TOKEN, page: page, per_page: per_page} resp requests.get(url, paramsparams, timeout15) resp.raise_for_status() return resp.json() # 删除指定仓库 def delete_repo(owner, repo): url fhttps://gitee.com/api/v5/repos/{owner}/{repo} params {access_token: TOKEN} resp requests.delete(url, paramsparams, timeout15) return resp.status_code if __name__ __main__: repos list_repos() for r in repos: name r[full_name] # 只处理名字里带 temp- 前缀的临时仓库避免误删 if r[name].startswith(temp-): print(f准备处理: {name}) # 先打印确认确认无误后再取消下面这行的注释 # code delete_repo(r[namespace][path], r[name]) # print(f{name} - {code})使用这类脚本有几条铁律我觉得比脚本本身更重要。第一令牌权限要最小化。生成令牌时只勾选需要的权限范围不要图省事全选。第二先跑只读逻辑把要动的仓库全部打印出来人工核对一遍。上面代码里删除那行我是注释掉的就是这个意思。删库这种操作没有回收站点下去就没了。第三加白名单或前缀过滤。上面用temp-前缀做过滤就是为了防止误伤正常项目。脚本里如果直接遍历全部仓库删风险太大。第四令牌不要写死在脚本里。用环境变量传进去避免脚本不小心提交到仓库里把令牌一起泄露了import os TOKEN os.environ.get(GITEE_TOKEN)这个习惯要养成因为一旦令牌跟着代码推上去了等于把你的账号操作权限公开了。另外如果只是想减少仓库数量而不是彻底删除可以把不常用的仓库归档或者转成私有这样也不会在列表里碍眼还保留了内容。同类操作在网页端也不是完全不能做但如果数量上了两位数脚本的效率优势就非常明显了。7. 最后聊几句我自己的使用体会从最早的图形客户端到后面完全切到终端中间我大概花了半年时间适应。一开始觉得敲命令慢后来发现真正慢的是点开客户端、等它加载、找菜单、点错、再找回来这一整套动作。终端里几行命令加上 tab 补全实际效率高得多尤其是在没有图形界面的服务器上。关于 Gitee 在 Linux 下的使用我个人最想强调的一点是把 SSH 密钥这段路走扎实剩下的都简单。我见过太多人卡在Permission denied (publickey)上反复折腾其实用ssh -vT gitgitee.com看一眼详细输出问题基本立刻就能定位——是密钥路径不对还是公钥没贴还是 config 里的 Host 撞了。另外一个小技巧分享给经常在不同机器之间来回切的人把你常用的~/.ssh/config和一份基础.gitignore模板放在一个私有仓库里新机器上git clone下来软链到对应位置五分钟就能把开发环境恢复到能用的状态。这个习惯我坚持了好几年换机器的时候省下的时间相当可观。代码托管这件事工具本身不复杂复杂的是各种边界情况。上面这些内容基本都是我在实际项目里撞出来的遇到了就记一笔攒到现在差不多覆盖了日常会碰到的绝大多数场景。