独立开发者的 Git 作战手册

· 英文版

作为独立开发者，我们不需要像大厂 DevOps 工程师那样精通 Git 的所有奇技淫巧。我们的目标只有一个：安全地管理代码，顺滑地发布产品。

这份手册整理了我开发 RustleFlow 过程中最高频使用的命令，涵盖了自动化发布、灾难恢复和日常开发流。

1. 发布与标签 (CI/CD 的扳机)

在我的自动化工作流（GitHub Actions）中，Git Tag（标签） 是触发构建和发布的唯一“扳机”。

标准发布流程

当你准备好发布 v0.1.0 版本时：

# 1. 打本地标签 (确保版本号与 package.json/tauri.conf.json 一致)
git tag v0.1.0

# 2. 推送标签到远程 (这会触发 Release Workflow)
git push origin v0.1.0

后悔药：删除与重打标签

如果是初次配置 CI/CD，经常会遇到构建失败的情况。这时候需要修改代码后，重新触发同一个版本号的构建。

注意：Git 标签只是便利贴，GitHub Release 是靶子。重打标签前，建议先去 GitHub 网页端手动删除失败的 Release 草稿。

# 1. 删除本地标签
git tag -d v0.1.0

# 2. 删除远程标签 (通知服务器撕掉便利贴)
git push --delete origin v0.1.0

# 3. 重新打标签并推送
git tag v0.1.0
git push origin v0.1.0

2. 修正与清理 (救火与强迫症)

修正上一次提交 (无痛改错)

刚敲完 git commit，突然发现注释写错了，或者漏了一个配置文件？不需要 reset 再重来，用这个命令直接覆盖上一次提交记录。

# 1. 修改文件或暂存漏掉的文件
git add .

# 2. 将变更合并到上一次 commit 中 (不会产生新的 commit 记录)
git commit --amend --no-edit

# 如果只是想改写 commit message：
git commit --amend -m "fix: 更正后的提交信息"

.gitignore 不生效时的“大扫除”

这是新手最容易踩的坑：明明把 .jks 或 node_modules 加入了 .gitignore，但 Git 依然在追踪它们。这是因为这些文件在规则生效前已经被 Git 收录了。

执行这一套“大扫除”命令，只清除索引，不删物理文件：

# 1. 清除缓存 (将所有文件移出暂存区)
git rm -r --cached .

# 2. 重新添加所有文件 (此时 .gitignore 规则会强制生效)
git add .

# 3. 提交变更
git commit -m "chore: refresh gitignore rules"

撤销上一次提交 (软着陆)

如果想完全撤回上一次提交，重新组织代码：

# 撤销最近一次 commit，但保留代码修改 (Soft Reset)
# 也就是把状态退回到 "git add" 之前
git reset --soft HEAD~1

放弃本地所有修改 (核弹)

代码改乱了，完全跑不起来，想回到上一次提交的干净状态。慎用！

git checkout .
# 或者 (更加彻底)
git reset --hard

3. 分支策略 (大胆实验的沙盒)

即使是独立开发，也不建议直接在 main 分支上开发复杂功能。开一个分支，就像开一个“沙盒”，搞砸了直接删掉分支即可，主程序毫发无损。

# 1. 创建并切换到新分支 (feat/xxx 是好习惯)
git checkout -b feat/dev

# ... 在这里尽情写代码，怎么乱都没事 ...

# 2. 功能开发完，切回主分支
git checkout main

# 3. 将新功能合并进主分支
git merge feat/dev

# 4. 删除由于已经合并而不再需要的分支
git branch -d feat/dev

4. 日常开发循环 (肌肉记忆)

这是每天重复无数次的三部曲：

# 1. 查看当前状态 (有哪些文件变了)
git status

# 2. 添加所有变更到暂存区
git add .

# 3. 提交并写备注 (feat: 新功能 / fix: 修Bug)
git commit -m "feat: add login page"

遇到冲突怎么办？(Don’t Panic)

当你 git pull 或 git merge 时，Git 可能会告诉你“Conflict”（冲突）。这只是 Git 在问你：“我不确定这两行代码该保留哪一行，你来定。”

  1. 打开冲突文件，搜索 <<<<<<<。
  2. 你会看到类似这样的结构： 
    <<<<<<< HEAD
我的代码 (当前分支)
=======
传入的代码 (远程或合并进来的分支)
>>>>>>> branch-name
  3. 物理删除你不想要的部分（包括那些尖括号符号），只保留你想要的代码。
  4. 保存文件，然后执行标准的 git add . 和 git commit 即可。

5. 暂存 (上下文切换)

正在写代码，突然有个紧急 Bug 要修，但手头的代码还跑不起来，不能提交。

# 把当前工作现场“冻结”起来
git stash

# ... (此时代码回到干净状态，可以去修 Bug 了) ...

# 修完 Bug 回来，恢复现场
git stash pop

经验之谈

  • 关于 SSH 连接：如果你的网络环境导致 SSH 连接 GitHub 经常超时，不要纠结于 Git 配置。最快的方案是直接修改 ~/.ssh/config 走代理，或者简单粗暴地换回 HTTPS 协议。
  • 关于密钥安全：永远不要把 .jks、.env 等敏感文件提交到仓库。一旦误传，即使删除了，历史记录里也有。遇到这种情况，请参考上文的“大扫除”并强制覆盖历史。

保持专注，最小行动。 我们不需要成为 Git 专家，只需要它成为我们发布产品的坚实地基。