git merge 默认创建合并提交导致主分支历史分叉；rebase 错误操作会丢 commit，仅限已推送的 commit；cherry-pick + reset --soft 是可控的单 commit 合入方式；merge --squash 会丢失作者信息和拓扑关联，不推荐用于功能交付。
为什么 merge 后主分支历史变分叉？
因为 git merge 默认创建合并提交（merge commit），只要功能分支有独立提交，主分支就会多出一个分叉节点。多人并行提交后，main 上会密集出现形如 Merge branch 'feat/login' 的提交，历史图变成网状，git bisect 和代码追溯都变困难。
rebase 用错会丢 commit 吗？
会，但只发生在你对已推送到远程的 commit 执行 git rebase -i 并修改、删除、重排之后。本地未推送的 commit 可以安全变基；一旦 push 过，再 rebase 就得强制推送（git push --force-with-lease），别人如果已基于旧历史工作，就会出问题。
- 永远不要对
main或develop这类共享分支做rebase -
rebase -i origin/main只应在自己的功能分支上运行 - 如果中途
git rebase卡住（比如冲突没解决完就退出编辑器），用git rebase --abort回退，别硬继续
cherry-pick + reset --soft 怎么压缩成单 commit？
这是最可控的“干净合入”方式：不污染功能分支，也不动 main，只把指定范围的变更拎出来，压成一条记录。关键不是命令本身，而是起点和范围必须精准。
Convert Github Repository
下载
适用于以下场景：（1）用户提供 GitHub 仓库 URL 或本地仓库路径，并请求将其转换为其他格式；（2）用户请求导出 GitHub 仓库……
- 先记下
main当前 HEAD：START=$(git rev-parse HEAD) - 用
git cherry-pick a1b2c3d^..e4f5g6h拣选（注意^表示从父提交开始） - 再
git reset --soft $START把暂存区保留、历史指针回退到起点 - 最后
git commit -m "feat(user): add login & profile"手动写清晰的单条提交信息
merge --squash 看似简单，为什么团队常禁用？
它确实能把一串 commit 压成一条，但会丢失原始作者信息和时间戳——所有变更都记在执行 merge --squash 的人名下。更严重的是，它切断了功能分支与主分支的拓扑关联，后续想查“这个功能最早在哪次提交引入”，git blame 或 git log --oneline --graph 都找不到源头。
真正需要“单条记录”的场景，应该用 cherry-pick + reset --soft，而不是 merge --squash。后者适合一次性脚本任务或临时修复，不适合功能交付。
