Git分支管理的高级策略
开发团队最头疼的就是分支混乱导致合并灾难。试试git rebase -i HEAD~3交互式变基，把凌乱的提交记录整理成逻辑清晰的版本历史。大型项目推荐采用Git Flow工作流：
feature/前缀用于新功能开发release/前缀用于预发布测试hotfix/前缀处理紧急缺陷develop作为集成分支master保持生产环境代码| 分支类型 | 生命周期 | 合并目标 |
|---|---|---|
| feature | 2-4周 | develop |
| hotfix | 1-3天 | master |
冲突解决的黄金法则
遇到合并冲突时别急着abort，先用git diff name-only diff-filter=U查看冲突文件列表。VSCode的GitLens插件能可视化冲突区块，比命令行更直观：
git checkout ours git checkout theirs 等标记符号git mergetool调用外部比对工具提交历史的艺术加工
git commit amend
能修改最近提交信息，配合git rebase -i可以：
注意：已推送到远程的提交不要修改，除非团队明确允许。强制推送(git push -f)可能造成协作灾难，私有分支可以酌情使用。
暂存区的妙用
git stash push -m "WIP: 实验性代码"
比直接commit更优雅：
stash list查看暂存栈stash apply@{1}恢复指定暂存stash show -p查看差异stash branch从暂存创建新分支配合git clean -fd能快速还原工作区，特别适合切换任务场景。.gitignore文件要定期更新，避免误提交构建产物和IDE配置。
rebase冲突这事儿，说白了就是分支太久没同步惹的祸。最靠谱的做法是养成习惯，每次准备rebase前先来个标准三连：git fetch拉取远程最新代码，git merge origin/目标分支把上游变更合并到本地，最后git rebase -i操作时就能避开80%的冲突。特别是那些要开发2-4周的feature分支，千万别等到最后才想起来rebase，每周定期做一次同步，合并冲突的难度直接降级成”简单模式”。
有个特别实用的技巧是用git rebase exec "测试命令" 目标分支，在每次rebase提交后自动运行测试。比如前端项目可以配npm test，后端项目用mvn test，这样能在冲突冒头的第一时间发现问题。要是团队里都在用VSCode，装个Git Graph插件实时可视化分支关系，谁落后了几个commit一目了然，比命令行查git log graph直观多了。记住，rebase不是洪水猛兽，关键是要像刷牙一样养成定期操作的习惯。
常见问题解答
如何避免在 rebase 过程中出现冲突？
在开始 rebase 前先执行 git fetch 和 git merge origin/目标分支，确保本地分支与远程同步。对于长期存在的 feature 分支， 每周执行一次 rebase 操作，而不是等到开发完成时才处理。
Git Flow 工作流适合3-5人的小团队吗？
对于小型团队，可以简化 Git Flow 流程。保留 master 和 develop 两个主分支，feature 分支生命周期控制在1-2周内，hotfix 直接合并到 master 后同步到 develop 即可，不需要严格遵循完整的 Git Flow。
强制推送后如何恢复被覆盖的提交？
使用 git reflog 查找被覆盖提交的哈希值，然后通过 git checkout -b 恢复分支 提交哈希 创建新分支。注意：这个方法只在本地仓库有效，如果其他成员已经拉取了被覆盖的分支，需要通知他们重置本地分支。
为什么我的 .gitignore 文件有时会失效？
.gitignore 只对未跟踪文件有效，如果文件已经被 git 跟踪，需要先执行 git rm cached 文件名 移除跟踪。另外注意 .gitignore 不支持已提交文件的排除，这类情况需要使用 git update-index assume-unchanged 文件名。
如何批量删除本地已合并的分支？
使用 git branch merged | grep -v “*” | grep -v “master” | grep -v “develop” | xargs -n 1 git branch -d 命令可以安全删除所有已合并到当前分支的本地分支，同时保护 master 和 develop 分支不被误删。
