git stash 保存当前修改再切分支需先暂存后新建分支，因Git禁止脏状态跨分支切换；推荐用git stash push -m带注释暂存，再git checkout -b创建分支并git stash pop恢复，冲突时需手动解决。
git stash 保存当前修改再切分支
直接 git checkout -b new-branch 会失败，因为工作区有未提交的修改，Git 不允许跨分支保留脏状态。最稳妥的做法是先暂存（stash）再新建分支。
-
git stash push -m "save work in progress"—— 推荐带 message，方便后续定位 -
git checkout -b feature/login—— 切到新分支 -
git stash pop—— 恢复修改（注意：如果冲突，会卡住，需手动解决）
这个流程适合修改不多、且不涉及大量二进制文件或 submodule 的场景。stash 本质是 commit-like 对象，但不关联任何分支，安全可靠。
git switch -c + git restore 避免 stash
如果你只想把「已暂存（staged）」的修改带到新分支，而丢弃工作区（untracked/unstaged）的临时改动，可以用更轻量的方式：
-
git add .先暂存所有想带走的变更（或选择性git add file1.js file2.css） -
git switch -c feature/api-v2—— Git 2.23+ 推荐替代checkout -b -
git restore --staged .—— 取消暂存（可选，按需）
这种方式不会生成 stash 记录，也不触发 merge 冲突风险，但要求你明确区分 staged / unstaged 状态。新手容易漏掉 git add 这一步，结果新分支里什么都没有。
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
git cherry-pick 仅转移特定 commit
如果当前分支已有若干 commit，你想把其中某几个“干净的提交”（即已 commit、无冲突、无依赖未提交修改）搬到新分支，cherry-pick 更精准：
-
git log --oneline -n 5查看最近提交，记下目标abc1234、def5678 git switch -c hotfix/timeout-
git cherry-pick abc1234 def5678—— 多个 hash 可空格分隔
注意：cherry-pick 会重放 commit，产生新 hash；如果原 commit 依赖尚未推送的其他改动，或者含 submodule 更新，可能失败。它不处理工作区未 commit 的内容——这点常被误以为能“搬修改”。
常见错误：git checkout -b 强制覆盖失败
执行 git checkout -b new-branch 报错 error: Your local changes to the following files would be overwritten by checkout，说明 Git 拒绝覆盖工作区文件。这不是 bug，是保护机制。
- 别用
--force或-f参数硬切——它只会丢弃你的修改 - 别在没
add的情况下直接switch -c——新分支将不含任何改动 - 别把
git merge当搬运工具——merge 是合并历史，不是移动修改
真正需要“转移修改”的时候，核心判断点只有一个：这些修改是否已经 commit？是 → 用 cherry-pick；否 → 必须先 stash 或 add + commit 再操作。很多人卡在这一步，反复试错却没意识到状态归属问题。
