Shaping Git history: rebase, cherry-pick, bisect
You learn to rewrite history safely, move changes between branches and find the commit that introduced a bug.
Level 201 · 16 lessons · 15 practice labs
Lessons
Rebase
- What rebase is and how it differs from merge
- Interactive rebase: reorder, squash, split
- Fixup commits and autosquash
- Rebase conflicts and backing out safely
- Not rewriting shared history, and force-with-lease
- Short task: turn a messy feature branch into clean commits
Moving changes
- Moving a single change with cherry-pick
- Backporting a fix to an older release
- Reverting a merge commit
- Short task: carry a security fix back to two older releases
Finding the bug in history
- Searching history with log -S, -G and --follow
- A line’s story with blame
- Binary search with bisect
- Automatic search with bisect run
- Short task: find the commit that made things slow
Wrap-up
- Capstone: clean up a release branch’s history and hunt down a bug
Practice labs
- Fold the WIP commits: Fold the ‘wip’ commits at the end of the branch into one descriptive commit with interactive rebase and prove with git diff that the file contents did not change.
- Two fixes noticed too late: Create the fixes for two older commits as fixup commits, slot them in with autosquash and show the tests pass at every step of the rebase.
- A giant commit that needs splitting: Split a large commit mixing a refactor and a new feature into two logical commits and prove with rebase --exec that tests pass on both.
- A rebase left half-done: Safely abort the rebase left half-done and confirm with ORIG_HEAD and the reflog that the branch is back to its pre-rebase state.
- Work about to be overwritten: Try to push your rewritten branch with --force-with-lease after a teammate pushed new commits, notice the refusal, take their work into your branch, then push safely.
- The branch underneath was rewritten: The shared branch you built on was rebased by someone else; move your own commits onto the new base without duplicates and show with git log that each commit appears only once.
- Carry one fix across: Carry a single fix from the development branch to the release branch with a note naming its source and show the source commit reference in git log.
- An old release where the file was renamed: Cherry-pick a fix into an older release of Tulip Pharmacy’s stock app where the file names differ, resolve the conflict and prove the old release’s tests pass.
- Which release is missing which fix?: Compare patch-equivalent commits between three release branches and main with git cherry, produce a table of the missing fixes and apply only the missing ones.
- Undo a bad merge: Revert the merge commit that broke main by picking the right parent and show with the test script that the app is back to its working state.
- Bring back a reverted feature: Merge back a feature branch that was reverted and later fixed, reverting the revert so the old changes also return, and prove the result is complete.
- Three reverts, one of them a merge: Revert three bad changes, one of them a merge commit, in the right order while resolving conflicts, and show both that tests pass and that history was not rewritten.
- Who added this line?: Find the commit that first added a configuration line that was later moved between files using blame options, and report its author, date and message.
- Trace a vanished function: Find the commits where a function was removed and its file renamed using log -S and --follow, and bring the function back in its last form.
- Bisect with commits that don’t build: Find the commit that introduced the bug in Demirhan Machinery’s calculation tool with bisect run, writing a test script that skips commits that don’t build, and report the commit with evidence.
About this course
You learn to rewrite history safely, move changes between branches and find the commit that introduced a bug.
What you will learn
- Rebase
- Moving changes
- Finding the bug in history
- Wrap-up
Prerequisites
Finishing the level 101 courses of the same path, or knowing those topics, is enough.
Lab environment
Lessons run in your own Kali Linux terminal that opens in the browser. Nothing to install; the lab starts clean in every lesson.
Frequently asked questions
- Is this course right for my level?
- The course is at level 201; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.