Git Advanced Workflows
Master advanced Git techniques to maintain clean history, collaborate effectively, and recover from any situation with confidence.
When to Use This Skill
- - Cleaning up commit history before merging
- Applying specific commits across branches
- Finding commits that introduced bugs
- Working on multiple features simultaneously
- Recovering from Git mistakes or lost commits
- Managing complex branch workflows
- Preparing clean PRs for review
- Synchronizing diverged branches
Core Concepts
1. Interactive Rebase
Interactive rebase is the Swiss Army knife of Git history editing.
Common Operations:
- -
pick: Keep commit as-is - INLINECODE1 : Change commit message
- INLINECODE2 : Amend commit content
- INLINECODE3 : Combine with previous commit
- INLINECODE4 : Like squash but discard message
- INLINECODE5 : Remove commit entirely
Basic Usage:
CODEBLOCK0
2. Cherry-Picking
Apply specific commits from one branch to another without merging entire branches.
CODEBLOCK1
3. Git Bisect
Binary search through commit history to find the commit that introduced a bug.
CODEBLOCK2
Automated Bisect:
CODEBLOCK3
4. Worktrees
Work on multiple branches simultaneously without stashing or switching.
CODEBLOCK4
5. Reflog
Your safety net - tracks all ref movements, even deleted commits.
CODEBLOCK5
Practical Workflows
Workflow 1: Clean Up Feature Branch Before PR
CODEBLOCK6
Workflow 2: Apply Hotfix to Multiple Releases
CODEBLOCK7
Workflow 3: Find Bug Introduction
CODEBLOCK8
Workflow 4: Multi-Branch Development
CODEBLOCK9
Workflow 5: Recover from Mistakes
CODEBLOCK10
Advanced Techniques
Rebase vs Merge Strategy
When to Rebase:
- - Cleaning up local commits before pushing
- Keeping feature branch up-to-date with main
- Creating linear history for easier review
When to Merge:
- - Integrating completed features into main
- Preserving exact history of collaboration
- Public branches used by others
CODEBLOCK11
Autosquash Workflow
Automatically squash fixup commits during rebase.
CODEBLOCK12
Split Commit
Break one commit into multiple logical commits.
CODEBLOCK13
Partial Cherry-Pick
Cherry-pick only specific files from a commit.
CODEBLOCK14
Best Practices
- 1. Always Use --force-with-lease: Safer than --force, prevents overwriting others' work
- Rebase Only Local Commits: Don't rebase commits that have been pushed and shared
- Descriptive Commit Messages: Future you will thank present you
- Atomic Commits: Each commit should be a single logical change
- Test Before Force Push: Ensure history rewrite didn't break anything
- Keep Reflog Aware: Remember reflog is your safety net for 90 days
- Branch Before Risky Operations: Create backup branch before complex rebases
CODEBLOCK15
Common Pitfalls
- - Rebasing Public Branches: Causes history conflicts for collaborators
- Force Pushing Without Lease: Can overwrite teammate's work
- Losing Work in Rebase: Resolve conflicts carefully, test after rebase
- Forgetting Worktree Cleanup: Orphaned worktrees consume disk space
- Not Backing Up Before Experiment: Always create safety branch
- Bisect on Dirty Working Directory: Commit or stash before bisecting
Recovery Commands
CODEBLOCK16
Resources
- - references/git-rebase-guide.md: Deep dive into interactive rebase
- references/git-conflict-resolution.md: Advanced conflict resolution strategies
- references/git-history-rewriting.md: Safely rewriting Git history
- assets/git-workflow-checklist.md: Pre-PR cleanup checklist
- assets/git-aliases.md: Useful Git aliases for advanced workflows
- scripts/git-clean-branches.sh: Clean up merged and stale branches
Git 高级工作流
掌握高级 Git 技巧，维护清晰的历史记录，高效协作，并自信地从任何情况中恢复。
何时使用此技能
- - 在合并前清理提交历史
- 在分支间应用特定提交
- 查找引入错误的提交
- 同时处理多个功能
- 从 Git 错误或丢失的提交中恢复
- 管理复杂的分支工作流
- 准备干净的拉取请求以供审查
- 同步已分叉的分支
核心概念
1. 交互式变基
交互式变基是 Git 历史编辑的瑞士军刀。
常见操作：
- - pick：保留提交原样
- reword：更改提交信息
- edit：修改提交内容
- squash：与上一个提交合并
- fixup：类似 squash 但丢弃提交信息
- drop：完全删除提交
基本用法：
bash
变基最后 5 个提交
git rebase -i HEAD~5
变基当前分支上的所有提交
git rebase -i $(git merge-base HEAD main)
变基到特定提交
git rebase -i abc123
2. 挑选提交
将一个分支的特定提交应用到另一个分支，无需合并整个分支。
bash
挑选单个提交
git cherry-pick abc123
挑选提交范围（不包含起始提交）
git cherry-pick abc123..def456
挑选但不提交（仅暂存更改）
git cherry-pick -n abc123
挑选并编辑提交信息
git cherry-pick -e abc123
3. Git 二分查找
通过提交历史进行二分查找，找到引入错误的提交。
bash
开始二分查找
git bisect start
标记当前提交为坏
git bisect bad
标记已知的好提交
git bisect good v1.0.0
Git 会检出中间的提交 - 测试它
然后标记为好或坏
git bisect good # 或：git bisect bad
继续直到找到错误
完成后
git bisect reset
自动二分查找：
bash
使用脚本自动测试
git bisect start HEAD v1.0.0
git bisect run ./test.sh
test.sh 应返回 0 表示好，1-127（除 125 外）表示坏
4. 工作树
同时处理多个分支，无需暂存或切换。
bash
列出现有工作树
git worktree list
为功能分支添加新工作树
git worktree add ../project-feature feature/new-feature
添加工作树并创建新分支
git worktree add -b bugfix/urgent ../project-hotfix main
移除工作树
git worktree remove ../project-feature
清理过期工作树
git worktree prune
5. 引用日志
你的安全网 - 跟踪所有引用移动，甚至包括已删除的提交。
bash
查看引用日志
git reflog
查看特定分支的引用日志
git reflog show feature/branch
恢复已删除的提交
git reflog
找到提交哈希
git checkout abc123
git branch recovered-branch
恢复已删除的分支
git reflog
git branch deleted-branch abc123
实用工作流
工作流 1：在拉取请求前清理功能分支
bash
从功能分支开始
git checkout feature/user-auth
交互式变基以清理历史
git rebase -i main
变基操作示例：
- 合并修复拼写错误的提交
- 重写提交信息以使其清晰
- 按逻辑顺序重新排列提交
- 删除不必要的提交
强制推送清理后的分支（如果没有其他人使用则安全）
git push --force-with-lease origin feature/user-auth
工作流 2：将热修复应用到多个版本
bash
在主分支上创建修复
git checkout main
git commit -m fix: 关键安全补丁
应用到发布分支
git checkout release/2.0
git cherry-pick abc123
git checkout release/1.9
git cherry-pick abc123
处理可能出现的冲突
git cherry-pick --continue
或
git cherry-pick --abort
工作流 3：查找错误引入点
bash
开始二分查找
git bisect start
git bisect bad HEAD
git bisect good v2.1.0
Git 检出中间的提交 - 运行测试
npm test
如果测试失败
git bisect bad
如果测试通过
git bisect good
Git 会自动检出下一个要测试的提交
重复直到找到错误
自动版本
git bisect start HEAD v2.1.0
git bisect run npm test
工作流 4：多分支开发
bash
主项目目录
cd ~/projects/myapp
为紧急错误修复创建工作树
git worktree add ../myapp-hotfix hotfix/critical-bug
在单独的目录中处理热修复
cd ../myapp-hotfix
进行更改，提交
git commit -m fix: 解决关键错误
git push origin hotfix/critical-bug
返回主工作而不中断
cd ~/projects/myapp
git fetch origin
git cherry-pick hotfix/critical-bug
完成后清理
git worktree remove ../myapp-hotfix
工作流 5：从错误中恢复
bash
意外重置到错误的提交
git reset --hard HEAD~5 # 哦不！
使用引用日志查找丢失的提交
git reflog
输出显示：
abc123 HEAD@{0}: reset: moving to HEAD~5
def456 HEAD@{1}: commit: 我的重要更改
恢复丢失的提交
git reset --hard def456
或从丢失的提交创建分支
git branch recovery def456
高级技巧
变基与合并策略
何时使用变基：
- - 在推送前清理本地提交
- 保持功能分支与主分支同步
- 创建线性历史以便于审查
何时使用合并：
- - 将完成的功能集成到主分支
- 保留协作的确切历史
- 其他人使用的公共分支
bash
使用主分支的更改更新功能分支（变基）
git checkout feature/my-feature
git fetch origin
git rebase origin/main
处理冲突
git status
修复文件中的冲突
git add .
git rebase --continue
或改用合并
git merge origin/main
自动压缩工作流
在变基期间自动压缩修复提交。
bash
进行初始提交
git commit -m feat: 添加用户认证
稍后，修复该提交中的某些内容
暂存更改
git commit --fixup HEAD # 或指定提交哈希
进行更多更改
git commit --fixup abc123
使用自动压缩进行变基
git rebase -i --autosquash main
Git 会自动标记修复提交
拆分提交
将一个提交拆分为多个逻辑提交。
bash
开始交互式变基
git rebase -i HEAD~3
将要拆分的提交标记为edit
Git 会在该提交处停止
重置提交但保留更改
git reset HEAD^
按逻辑块暂存和提交
git add file1.py
git commit -m feat: 添加验证
git add file2.py
git commit -m feat: 添加错误处理
继续变基
git rebase --continue
部分挑选
仅从提交中挑选特定文件。
bash
显示提交中的文件
git show --name-only abc123
从提交中检出特定文件
git checkout abc123 -- path/to/file1.py path/to/file2.py
暂存并提交
git commit -m cherry-pick: 应用来自 abc123 的特定更改
最佳实践
- 1. 始终使用 --force-with-lease：比 --force 更安全，防止覆盖他人的工作
- 仅变基本地提交：不要变基已推送和共享的提交
- 描述性提交信息：未来的你会感谢现在的你
- 原子提交：每个提交应是一个单一的逻辑更改
- 强制推送前测试：确保历史重写没有破坏任何内容
- 保持引用日志意识：记住引用日志是你的 90 天安全网
- 在风险操作前创建分支：在复杂变基前创建备份分支
bash
