git pull --rebase 更适合多人并行开发，因其将本地提交重放到远程最新提交后，保持线性历史，避免“merge branch”等冗余提交；而 git pull 默认执行 merge，易导致历史杂乱、log 难读。
git pull --rebase 要比 git pull 更适合多人并行开发
直接用 git pull 合并远程变更，会在本地历史中插入一个多余的 merge 提交，导致提交线杂乱、git log --oneline 难以阅读。而 git pull --rebase 会把你的本地提交“重放”到远程最新提交之后，保持线性历史，方便追踪功能演进。
常见错误现象：团队里有人频繁看到“Merge branch 'main' into feature/login”，但没人改过 main，这就是没加 --rebase 的典型副作用。
- 执行前确保你没有未提交的修改（否则 rebase 会中断）
- 如果本地已有多个提交，
--rebase可能触发冲突，需逐个解决并git add+git rebase --continue - 不要对已推送到远程的提交做 rebase —— 这会改写历史，别人再
pull就会出错
feature 分支命名必须带 scope 前缀
像 feature/user-login、hotfix/api-timeout、chore/ci-update 这类带作用域的命名，不是为了好看，而是让 CI/CD 流水线、PR 自动分类、Git hooks 和团队成员一眼识别意图。没有前缀的分支如 login 或 fix 在多人仓库里极易撞名、混淆用途。
使用场景：CI 系统可基于前缀自动触发不同测试套件；代码审查时，评审者看到 refactor/ 就知道要重点看兼容性，看到 test/ 就跳过逻辑审查。
- 推荐前缀：
feature/、bugfix/、hotfix/、refactor/、test/、chore/ - 避免使用
dev、temp、new等无意义词 - 团队应统一约定是否允许下划线（如
feature/user_login），避免混合风格
远程分支删了，本地 git branch -a 还显示？
这是 Git 的设计机制：本地仍保留对远程分支的引用缓存（remote-tracking branch），比如 origin/feature/old-api。它不占用空间，但会干扰 git branch -r 输出，也容易让人误以为分支还存在。
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
正确清理方式不是手动删文件，而是运行：
git fetch --prune
或更彻底的：
git remote prune origin
建议把它加入日常同步流程，比如在 git pull --rebase 前加一句 git fetch --prune，避免长期积累陈旧引用。
- 别用
git branch -d -r origin/xxx—— 这只是删本地缓存，下次fetch又回来 -
--prune不会影响你本地的 feature 分支，只清理已不存在的远程跟踪分支 - 某些 CI 工具（如 GitHub Actions）默认启用 prune，但本地终端不会自动开启
合并前必须先 rebase，而不是 merge
当你要把 feature/user-login 合入 main，如果直接 git checkout main && git merge feature/user-login，会产生一个 merge commit，且可能把 feature 分支里早已被修复的冲突又带进来。正确做法是先 rebase 到最新 main，再 fast-forward 合并或 squash 提交。
性能影响：rebase 后的合并通常是 fast-forward，不新增 commit；而 merge 每次都生成新节点，长期下来 git log 里 merge 提交占比超 30%，就说明流程有优化空间。
- 操作顺序：
git checkout feature/user-login→git rebase main→ 解决冲突 →git push --force-with-lease origin feature/user-login -
--force-with-lease比--force安全，它会检查远程分支是否被他人更新，防止覆盖他人推送 - 如果该分支已被他人基于它继续开发，就不能 force push —— 此时应改用 merge，并接受那个 merge commit
