git 2.23+ 推荐用 git switch -c，它专注创建并切换分支，语义清晰、安全性高；git checkout -b 兼容旧版本但功能混杂，易误操作。
直接在 master（或 main）上写代码，等于把所有人共用的生产环境当草稿纸——改错一行，全队卡住。分支不是“可选项”，是多人协作的生存底线。
git switch -c 和 git checkout -b 选哪个？
Git 2.23+ 推荐用 git switch -c，它只干一件事：创建并切换分支，语义干净、无歧义。而 git checkout 是个“多面手”，既能切分支、又能恢复文件、还能检出旧提交，容易误操作。
-
git switch -c feature/login：安全、明确，适合日常新建功能分支 -
git checkout -b feature/login：兼容老版本 Git（ - 别混用：
git switch不能恢复文件，git restore才是它的搭档；想用checkout恢复单个文件？必须加--防止被当成分支名，比如git checkout -- src/App.js
分支名为什么必须用 feature/、bugfix/ 这种前缀？
不是为了好看，是为了让 git branch 输出可读、可筛选、可自动化。没有前缀的分支名（如 login、fix）在多人仓库里会迅速变成一团乱麻。
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
- 团队协作中，
git branch --format="%(refname:short)" | grep "^feature/"可一键列出所有功能分支 - CI/CD 流水线常按前缀触发不同流程：匹配
feature/*运行单元测试，release/*自动打 tag - 远程推送时，前缀天然隔离命名空间：
git push origin feature/login不会和bugfix/login冲突 - 别用大写、空格、下划线——
Feature_Login在某些 CI 环境里会被截断或报错，一律小写 + 连字符，如feature/user-login-flow
切换分支时报 “Your local changes would be overwritten” 怎么办？
这不是 Git 在刁难你，是它在阻止你丢代码。这个错误说明你当前工作区/暂存区有未提交的修改，而目标分支里同名文件在对应位置有不同内容。
- 先执行
git status看哪些文件被改动，判断是否要保留 - 想暂存起来以后用：
git stash push -m "wip: login ui"，切完再git stash pop - 确定不要这些改动：
git restore .（丢弃所有工作区变更）或git restore --staged .（只清暂存区） - 硬切（不推荐）：
git checkout -f feature/login，会强制覆盖工作区，且无法撤销——除非你刚改的代码还在终端历史里
为什么刚创建的分支里有 master 的全部文件？
因为分支只是指向某个提交的指针，git switch -c feature/login 默认从当前 HEAD 创建，也就是从 master 最后一次提交开始分叉。它不是复制文件，而是共享历史快照。
- 你在
feature/login里新增Login.js，master里看不到；但package.json和README.md这些已有文件，两个分支都指向同一个 commit 对象 - 所以删分支不会删文件，
git branch -d feature/login只是删掉那个指针；只有所有分支都不再引用某次提交时，Git 的 GC 才可能回收它 - 真正危险的操作是
git reset --hard或强制推送git push --force-with-lease，它们会移动分支指针并丢弃提交，不是“删分支”本身的问题
分支管理最易被忽略的一点：没人会帮你清理已合并的远程分支。git branch -d 只删本地，origin/feature/login 还挂在远程服务器上——下次 git fetch 仍会拉下来，日积月累，git branch -a 列表会越来越长。定期执行 git push origin --delete feature/login 才算真正闭环。
