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 / Ubuntu | sudo apt update && sudo apt install git | 老版本系统建议加官方 PPA 升级 |
| CentOS / RHEL 7 | sudo yum install git | 自带版本偏旧，可考虑源码编译 |
| CentOS / RHEL 8+ | sudo dnf install git | 版本相对新，够用 |
| Arch / Manjaro | sudo pacman -S git | 版本一直很新 |
| openSUSE | sudo 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 git@gitee.com第一次连接会提示是否信任这个主机的指纹，输入yes。看到类似Hi 你的用户名! You've 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 git@gitee.com就会自动用指定的密钥了。这个 config 文件还有一个好处：如果你同时要用多个平台，可以给每个配一段，互不干扰。
2.3 HTTPS 和 SSH 的取舍
虽然我推荐 SSH，但也不能说 HTTPS 就一无是处。实际选型上，两种方式各有场景：
| 对比项 | SSH | HTTPS |
|---|---|---|
| 认证方式 | 密钥对 | 账号密码或个人访问令牌 |
| 是否需要重复输入 | 配好后不需要 | 默认每次都要，可用 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 git@gitee-work:公司命名空间/仓库名.git验证也是用别名：
ssh -T git@gitee-work我踩过一次坑，两个块都写了Host gitee.com，结果 git 只认第一个块里的密钥，公司仓库怎么推都是权限拒绝。后来才搞明白，同名 Host 后面的会被前面的覆盖掉，要用别名区分。
提示：
ssh -vT git@gitee.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 git@gitee.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 git@gitee.com:你的用户名/新仓库.git # 或者删掉重新加 git remote remove origin git remote add origin git@gitee.com:你的用户名/新仓库.git # 推送所有分支 git push -u origin --all # 如果要连标签一起推 git push origin --tags--all和--tags这两个参数经常被漏掉。只推当前分支的话，其他分支和所有标签都不会过去，等你换台机器 clone 下来发现少东西，还得回头补推。
3.4 首次推送最常撞上的几个报错
我把第一次推送时高频出现的报错整理成一张表，配上官方的排查方向：
| 报错信息关键词 | 大概率原因 | 处理方向 |
|---|---|---|
Permission denied (publickey) | 密钥没配对、公钥没贴、用了错的 Host | ssh -vT看用了哪个私钥 |
remote: Incorrect username or password | 用了 HTTPS 地址但密码错 | 换成 SSH 地址，或用令牌 |
failed to push some refs | 远程有本地没有的提交 | 先git pull --rebase |
src 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 默认走 rebase：
git 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，检出的时候不做转换。这样仓库里统一是 LF，Linux 本地文件也是 LF，干净。
更好的做法是在项目根目录放一个.gitattributes文件，把规则固化在仓库里：
* text=auto eol=lf *.sh text eol=lf *.bat text eol=crlf *.png binary *.jpg binary这样不管谁 clone 下来，规则都一致，不依赖个人电脑上的配置。.sh脚本文件一定要指定eol=lf，因为脚本里混进 CRLF 之后，Linux 上执行会报bad interpreter: No such file or directory，这个错误信息极其误导人，实际上就是多了个隐藏的\r。
5.2 权限位变化引起的满屏 mode change
Linux 下每个文件都有权限位（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，比如LANG=zh_CN.UTF-8。如果全是POSIX或者C，那中文基本会出问题。临时调整：
export LANG=zh_CN.UTF-8 export LC_ALL=zh_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(page=1, per_page=100): url = "https://gitee.com/api/v5/user/repos" params = {"access_token": TOKEN, "page": page, "per_page": per_page} resp = requests.get(url, params=params, timeout=15) resp.raise_for_status() return resp.json() # 删除指定仓库 def delete_repo(owner, repo): url = f"https://gitee.com/api/v5/repos/{owner}/{repo}" params = {"access_token": TOKEN} resp = requests.delete(url, params=params, timeout=15) 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 git@gitee.com看一眼详细输出，问题基本立刻就能定位——是密钥路径不对，还是公钥没贴，还是 config 里的 Host 撞了。
另外一个小技巧分享给经常在不同机器之间来回切的人：把你常用的~/.ssh/config和一份基础.gitignore模板放在一个私有仓库里，新机器上git clone下来软链到对应位置，五分钟就能把开发环境恢复到能用的状态。这个习惯我坚持了好几年，换机器的时候省下的时间相当可观。
代码托管这件事，工具本身不复杂，复杂的是各种边界情况。上面这些内容基本都是我在实际项目里撞出来的，遇到了就记一笔，攒到现在差不多覆盖了日常会碰到的绝大多数场景。
