Git 边边角角
内容提要
本文介绍 Git 实用技巧：用 --no-ff 禁用快进合并以保留分支信息；用 git stash 储藏未提交修改，便于切换分支修 bug；列出常用钩子；对比 merge 与 rebase——merge 保留完整历史，适合共享分支；rebase 历史呈直线但会重写提交，适合个人开发，可用 -i 压缩整理提交。
延伸解读
快进合并与分支信息保留
默认的 fast-forward 合并会直接移动分支指针，导致分支历史信息丢失。使用 --no-ff 参数可以强制生成一个新的合并提交，从而在历史中保留分支结构。这对于需要追踪功能分支合并记录的团队协作场景尤为重要，但也会使提交历史更加复杂。
储藏修改的典型场景
当在 dev 分支开发未完成时，若需紧急修复 master 上的 bug，直接切换分支会导致未提交修改被带到新分支。git stash 可将当前修改暂存到栈中，使工作区恢复干净，从而安全切换分支。修复完成后，可通过 git stash apply 恢复之前的工作进度。
merge 与 rebase 的适用选择
merge 保留完整历史，适合共享分支，避免重写已推送的提交；rebase 生成线性历史，适合个人开发，但会重写提交，导致提交哈希变化。若分支与他人共享，应避免使用 rebase。此外，rebase 可通过 -i 交互式压缩整理提交，使历史更简洁。
冲突处理与操作风险
rebase 一次只处理一个冲突，merge 则一次性处理所有冲突。因此，冲突较少时 rebase 更便捷；但若冲突较多，撤销 rebase 比撤销 merge 更复杂，因为 merge 只需撤销一次合并提交。选择时需权衡操作便利性与回退成本。
Q&A
Git 合并时如何保留分支信息？
使用 git merge --no-ff -m "merge with no-ff" 分支名 来禁用快进合并，这样会创建一个新的合并提交，从而在历史中保留分支信息。
git stash 有什么作用？
git stash 可以将当前分支未提交的修改储藏起来，使工作区变得干净，从而可以安全地切换到其他分支。之后可以用 git stash apply 恢复储藏的内容。
git merge 和 git rebase 有什么区别？
git merge 会保留完整的历史记录，合并后历史呈交叉线；git rebase 会将当前分支的提交移动到目标分支的末尾，历史呈直线，但会重写提交历史。merge 适合共享分支，rebase 适合个人开发。
什么时候应该使用 git rebase？
当只有你个人开发，或者想要整理提交历史时，推荐使用 git rebase。可以用 git rebase -i 来压缩和简化提交历史，将多个细碎的提交合并成一个详细的提交。
git rebase 处理冲突有什么特点？
git rebase 一次只处理一个冲突，而 git merge 一次处理全部冲突。因此处理冲突时 rebase 更方便，但如果冲突很多，撤销一个 rebase 会比撤销 merge 更复杂。
Git 有哪些常用的钩子？
Git 钩子包括：applypatch-msg、post-merge、pre-auto-gc、prepare-commit-msg、commit-msg、post-receive、pre-commit、push-to-checkout、post-applypatch、post-rewrite、pre-push、update、post-checkout、post-update、pre-rebase、post-commit、pre-applypatch、pre-receive。
