Great work!

XP to next level

BugEater
EN

reword, edit, drop and Reordering

Learning Objectives

By the end of this lesson you will be able to:

  • Fix a bad commit message anywhere in your branch, not just the last one
  • Stop at a commit with edit to amend it or split it into two
  • Remove a commit entirely, and predict when that will conflict
  • Reorder commits so related work sits together

reword: Fixing a Message

git commit --amend fixes the message of the last commit. reword fixes any of them.

pick   1a77c60 add refund boundary tests
reword 9d3e072 asdf
pick   4c1f8ab test: add currency rounding cases

Save, and Git replays the first commit, then stops and opens an editor containing asdf. Write a real message, save, and it carries on by itself. No --continue needed for a reword — Git resumes as soon as the editor closes.

This matters more than it looks. Commit messages are the only documentation that is guaranteed to still exist in two years, and a branch where one commit says asdf is a branch where the reviewer stops trusting all the others.

edit: Stopping Inside a Commit

edit replays the commit and then stops, leaving you standing on it with a shell prompt.

pick 1a77c60 add refund boundary tests
edit 9d3e072 test: add currency rounding cases
pick 4c1f8ab test: add timezone cases
Stopped at 9d3e072...  test: add currency rounding cases
You can amend the commit now, with

  git commit --amend

Once you are satisfied with your changes, run

  git rebase --continue

Two things people use this for.

Amending an Old Commit

You left a console.log in a commit three back. Change the file, then:

git add tests/payments/rounding.spec.ts
git commit --amend --no-edit
git rebase --continue

--no-edit keeps the existing message. The commit now looks as though it never had the stray line.

Splitting One Commit Into Two

A commit that changed both a fixture and a test should probably be two commits. Stop at it, then undo just the commit while keeping its changes in the working directory:

git reset HEAD~                    # commit undone, changes still in the files
git add tests/fixtures/payment.ts
git commit -m "test: extract payment fixture builder"
git add tests/payments/rounding.spec.ts
git commit -m "test: add currency rounding cases"
git rebase --continue

git reset HEAD~ is the --mixed reset from Module 4, used here in its most useful form. You will meet it properly there.

drop: Deleting a Commit

pick 1a77c60 add refund boundary tests
drop 9d3e072 debug: temporary logging
pick 4c1f8ab test: add timezone cases

The commit and its changes are gone from the branch. Deleting the line entirely does exactly the same thing — drop just makes the intent visible in the plan.

Expect a conflict when later commits depended on it. If 4c1f8ab edits a line that 9d3e072 introduced, removing 9d3e072 leaves 4c1f8ab trying to modify something that no longer exists. Git stops and asks. Resolve it as usual, or git rebase --abort and reconsider.

Dropping is right for genuinely unwanted commits: debug logging, a file committed by accident, an experiment that went nowhere. It is not the tool for undoing a change that other people already have — that is git revert, and it is Module 4.

Reordering

The lines can simply be moved:

pick 1a77c60 test: extract payment fixture builder
pick 4c1f8ab test: add refund boundary cases
pick 9d3e072 docs: update the test README

You wrote the README update in the middle of the work; moving it to the end groups the two test commits together and makes the branch read as a sequence rather than a diary.

Reordering is also how you set up a squash group whose newest message you want to keep — move that commit to the top of the group first, as the previous lesson described.

The same caution applies: if a commit depends on one that used to come before it, moving it produces a conflict. Small reorders are routine; shuffling ten interdependent commits is not worth the time.

Pro Tip: Do one kind of change per rebase. Squash in one pass, reorder in another, reword in a third. Three simple rebases each take a minute; one clever rebase that does everything at once is how you end up in a conflict you cannot reason about.

Where This Lands

A branch that arrives at review with three commits — extract the fixture, add the boundary cases, update the README — gets a different quality of review than one with nine commits called wip. The reviewer can follow your reasoning, comment on the right commit, and approve the parts that are obviously fine.

That is the entire return on this module, and it is large.

Key Takeaways

  • reword edits any commit's message; Git resumes automatically when the editor closes
  • edit stops on a commit so you can git commit --amend or split it with git reset HEAD~
  • Always git rebase --continue after an edit
  • drop, or deleting the line, removes a commit and its changes
  • Removing or moving a commit that later commits depend on produces a conflict — resolve or abort
  • Reorder lines to group related work, and to control which message survives a squash
  • One kind of change per rebase; several simple passes beat one complicated one

Quiz

Which command fixes the message of a commit that is not the most recent one?

What does edit do when the rebase reaches that commit?

Stopped at an edit, you want to split the commit into two. What is the first step?

You drop a commit and the rebase stops with a conflict. What most likely happened?