Clean Up Git Commit Messages

Rewrite messy Git commit messages locally with a browser-based tool.

Introduction

30 Second Summary

A project can work perfectly while its saved notes still read like a private conversation with a coding agent. Those notes become awkward when someone outside the team sees them.

In this project, you will use commit-rewriter to clean messy commit messages through a local browser app. You'll practise safely in a throwaway Git repository before applying the same workflow to a repository you own.

What You'll Build

You refresh your repository's log to see clear commit messages beside a timestamped backup branch that preserves the original history.

By the end of this project, you'll have:

A local editing workflow that shows your repository's commits in a browser. You can replace agent chatter with messages you would show another person.
Visible before-and-after proof of a history rewrite. You can compare the changed commit hashes with the originals on the timestamped backup branch.
A clean branch for your own repository with revised messages applied one commit at a time. You can push that branch without rewriting a shared branch by surprise.
Secret Mission: An optional challenge to push your history-rewriting skills further.

Are there any prerequisites?

You'll need Git plus uv on your laptop. You also need a repository you own, with no account or API key required.

Before We Start

This project rewrites Git commit history. Your core tools need to be ready before you touch a repository.

You'll prepare Git with your commit identity. You'll install uv so uvx can launch the local app later.

You'll also choose a repository you own for the final exercise.

In this step, get ready to:

Prepare Git with your commit identity.
Install uv so uvx can run Python-based tools.
Choose a real repository where you can push a branch.

Check Git and set your identity

Git records an author name plus an email address inside every commit. Setting that identity now gives the practice commits a clear owner.

Press Cmd+Space on macOS or the Windows key on Windows to open system search.
Type Terminal on macOS or PowerShell on Windows.
Press Enter to open the terminal.
Check whether Git is available by running this command:

git --version

What does this command do?

This asks Git to print its installed version. A version number confirms that your terminal can find the Git executable.

✔️ I see a Git version

Git is ready to manage the practice repository. You can continue with your commit identity.

ⓧ Git is missing

Install Git using the path for your operating system below.

macOS

Approve the developer tools installation prompted by the earlier Git check.
Return to the terminal from earlier when installation finishes.
Confirm Git is available by running this command:

git --version

What should you see?

Git prints a version number when the developer tools installation is complete. That output confirms the terminal can now use Git.

Windows

Download Git for Windows from the official Git download page.
Run the downloaded installer.
Keep the default options as you move through setup.
Return to PowerShell from earlier after installation.
Confirm Git is available by running this command:

git --version

What should you see?

Git prints a version number after the installer adds it to your system. That output confirms PowerShell can now find Git.

Linux

Choose the command that matches your Linux distribution. Your package manager may request an administrator password or confirmation.

Install Git on Debian or Ubuntu by running:

sudo apt install git-all

What does this command do?

The package manager installs the Git tools provided for Debian-based distributions.

Install Git on Fedora or a related distribution by running:

sudo dnf install git-all

What does this command do?

The package manager installs the Git tools provided for Fedora-based distributions.

Confirm Git is available by running this command:

git --version

What should you see?

Git prints a version number after the package installation completes. That output confirms the terminal can now use Git.

Your global Git identity becomes the default author information for new commits on this computer. You can override it inside an individual repository later.

Replace John Doe with your name in the first command below.
Replace johndoe@example.com with your email address in the second command below.
Configure your global Git identity by running both edited commands:

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

What do these commands do?

The user.name setting records the author name used for new commits.
The user.email setting records the author email used for new commits.
The --global option applies both values to repositories you use on this computer.

Before you check the configuration, do you think both edited values were saved?

Review your Git configuration by running:

git config --list

What should you see?

Look for user.name plus user.email in the output. Their values should match the identity you entered.

Identity missing from the list?

Run the two configuration commands again with your own values. Check that each command includes the global option.

Need help with the result? Help me configure my Git user name and email.

Install uv and verify uvx

The local commit editor is a Python-based tool. uv supplies the tool runner that downloads it into an isolated environment when you need it.

Check whether uv is already available by running:

uv --version

What does this command do?

This asks uv to print its installed version. A version number confirms that the terminal can find uv.

✔️ I see a uv version

Your uv installation is ready. The next check confirms that its tool runner is available too.

ⓧ uv is missing

Install uv using its official standalone installer for your operating system.

macOS

Install uv by running its official installer command:

curl -LsSf https://astral.sh/uv/install.sh | sh

What does this command do?

This downloads the official installation script over HTTPS. The script installs the uv executables for your user account.

Close the current terminal window after the installer finishes.
Return to Terminal using system search from earlier.

Windows

Install uv by running its official PowerShell installer command:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

What does this command do?

This downloads the official PowerShell installation script. The script installs the uv executables for your user account.

Close the current PowerShell window after the installer finishes.
Return to PowerShell using system search from earlier.

Linux

Install uv by running its official installer command:

curl -LsSf https://astral.sh/uv/install.sh | sh

What does this command do?

This downloads the official installation script over HTTPS. The script installs the uv executables for your user account.

Close the current terminal window after the installer finishes.
Return to the terminal using your application launcher.

Before you run the next check, do you think the uv tool runner is available in this terminal session?

Confirm the uv tool runner is available by running:

uvx --version

What is uvx?

The uvx command is an alias for the uv tool runner. A version number confirms that it can launch Python-based command-line tools.

uvx still unavailable?

Close the terminal after installation. Return to it through system search so the new session can load the updated executable path.

Still stuck? Help me make uvx available in my terminal.

Choose your real repository

The final exercise needs a repository where you control branch pushes. Choosing it now keeps the later history rewrite focused on a branch you own.

Press Cmd+Space on macOS or the Windows key on Windows to open system search.
Type the name of your web browser.
Press Enter to open the browser.

Your browser is ready when its window opens. Before you check the remote repository, do you expect your account to have branch controls there?

Choose a real repository that you own.
Open that repository's remote page in your browser.
Confirm that your account controls the repository.
Confirm that you have permission to create a branch.
Record the repository for later: your repository name.

Why ownership matters

A history rewrite changes every commit hash after the earliest edited commit. Shared branches need coordination because other contributors may still have the old hashes.

The backup branch created later stays on your computer until you push it. Keep it until you have checked the rewritten history.

Your repository choice is ready. Before you run the final checks, do you think both tools are available in this terminal session?

Confirm Git is still available by running:

git --version

Git check

You should see a Git version number. This confirms that the command is available for the practice repository.

Confirm the Python tool runner is available by running:

uvx --version

uvx check

You should see a uvx version number. This confirms that the local web app can be launched in the next part of the project.

Your tools and target repository are ready. Next up, you'll build a throwaway repository where you can practise rewriting history safely.

Create a Messy Practice Repo

A history rewrite feels risky when the only copy is a repository you care about. This practice repository gives you room to learn the workflow without touching real work.

You will create a small local Git history filled with the kind of agent chatter that makes a public log hard to read. Its commit hashes and messages become your baseline for the rewrite.

In this step, get ready to:

Create an isolated throwaway repository on your Desktop.
Fill the repository with three deliberately messy commits.
Inspect the original commit hashes and messages in your terminal.

Start in a safe folder

A Git repository stores its history inside a hidden .git directory. Initializing a separate folder keeps every experiment contained.

Switch back to the terminal from earlier.
Place the commit-rewriter-practice repository on your Desktop by running these commands:

cd ~/Desktop
mkdir commit-rewriter-practice
cd commit-rewriter-practice
git init

What do these commands do?

The first line moves your terminal to the Desktop. This keeps the practice folder easy to find.
The mkdir command creates the commit-rewriter-practice folder.
The final line creates the hidden .git directory that stores the repository history.

Check the final terminal line for confirmation that the repository was initialized inside commit-rewriter-practice.

Did the setup stop at the folder step?

Check that your terminal prompt ends in commit-rewriter-practice.
Move any existing commit-rewriter-practice folder off your Desktop.
Repeat the setup commands after the folder name is available.

Still stuck? Help me initialize my throwaway Git repository safely.

Your sandbox is ready for safe experiments inside this disposable repository.

Create deliberately messy commits

A commit pairs a saved project state with a message explaining the change. The --allow-empty option lets this practice history focus on messages without adding files.

Seed the history with issue references and agent chatter by running these commands:

git commit --allow-empty -m "AI agent: bootstrap project for issue #482"
git commit --allow-empty -m "Address reviewer feedback from internal ticket PROJ-731"
git commit --allow-empty -m "WIP agent cleanup and misc fixes"

What do these commands do?

Each line creates one commit with an intentionally unhelpful message.
The --allow-empty option lets Git record a commit even when no file content changed.
The -m option stores the following text as the commit message.

Check the terminal output for three separate commit summaries.
Match each summary to one of the messages in the command block.

Did commit creation stop?

Confirm that you are still inside commit-rewriter-practice.
Return to the previous substep if Git reports that the current folder is not a repository.

Need another pair of eyes? Help me work out why my empty practice commits are not being created.

You now have the intentionally noisy history that the editor will clean up.

Inspect the original commit log

The commit log is your before picture. Each row connects a commit hash to the message stored with that version of the history.

Before you run the check, which of your three messages do you expect to appear at the top?

Display the original history in a compact format by running this command:

git log --oneline

How do you read this log?

Each row represents one commit in the repository history.
The short value on the left is the commit hash.
The text on the right is the commit message.
Git lists the newest commit first.

Count the rows in the terminal output.
Confirm that each row starts with a short commit hash.
Confirm that all three messy messages appear in the log.

Are commits missing from the log?

Return to the previous substep if fewer than three rows appear.
Run only the commit commands that did not produce a summary.
Confirm that your terminal prompt still points to commit-rewriter-practice.

Still missing a commit? Help me compare my practice commands with my Git log.

That is your baseline captured. You can now recognize every original hash and message before anything rewrites the history.

Your original history is now recorded. Next, you will launch commit-rewriter with uvx and open its local web app.

Open the Commit Editor

Your throwaway Git repository now contains several messy commits. You have already inspected their original hashes and messages.

The terminal log gives you a precise record of the history. In this step, you will start commit-rewriter so the same commits appear in a browser form.

In this step, get ready to:

Run commit-rewriter against the throwaway repository with uvx.
Open the local commit editor in your browser.
Confirm that the editor lists the messy commit messages.

Use the current repository context

The terminal location tells commit-rewriter which repository to inspect. Running the tool from the terminal you used earlier points it at your throwaway history.

Return to the terminal where you inspected the throwaway repository log.
Start the local commit editor by running this command:

uvx commit-rewriter

What does this command do?

The uvx command runs commit-rewriter in an isolated environment without permanently installing it.
Omitting a repository path makes commit-rewriter use the current terminal directory.
The tool serves its browser interface at http://127.0.0.1:8000.

The first launch can take a little longer while uvx prepares the tool. A short pause here is expected.

Keep the terminal process running while you use the commit editor.

Open the browser editor

The running terminal process keeps the local web app available. The browser should show the same repository history you inspected earlier.

Before you load the page, predict which messy commit messages you expect to recognize from the original log.
Enter http://127.0.0.1:8000 in the address bar of the browser from earlier.

You should see the throwaway repository path near the top of the page. Below it, commit cards display the current branch history and its messages.

Compare the displayed repository path with the location of your throwaway repository.
Match at least two displayed commit messages with the original log you inspected.
Leave every commit message unchanged for now.

Local editor not loading?

Keep the terminal process running while the browser page is open.
Restart the tool from the terminal where you inspected the throwaway repository if the page shows commits from another repository.
Check that the browser address is exactly http://127.0.0.1:8000.

Still stuck? Help me diagnose why my local commit-rewriter page is not displaying the throwaway repository commits.

That connection is working. Your browser now displays the throwaway repository's messy commit messages.

Your local editor is connected to the throwaway repository. Next up, you will replace a few messy messages through the browser form.

Rewrite the Practice Messages

Your throwaway Git repository is now visible in the commit-rewriter local app. The deliberately messy messages from earlier are ready to edit.

A history rewrite can feel risky because it replaces the current line of commits. This practice run stays contained inside your throwaway repository.

The tool creates a timestamped backup branch before it updates the current branch. You can focus on improving the messages while the original history stays available.

In this step, get ready to:

Replace two or three messy commit messages with clear descriptions.
Review the original messages beside your proposed messages.
Submit the rewrite and confirm that the backup branch was created.

Write clear replacement messages

A useful commit message names the concrete change captured by that commit. Clear subjects make the history easier to scan later.

Return to the local commit-message editor from the previous step.
Choose two or three messy commits from the list.
Replace each chosen message in its text area with a short description of the change.
Keep the first line focused on one change.

The pending-edit counter should now show 2 pending edits or 3 pending edits. Each edited commit card should also have a green border.

Select Edited only in the toolbar.

You'll see only the two or three commits you changed. This filtered view confirms that the correct messages are queued.

Review the proposed changes

The review screen is your final checkpoint before the repository changes. It places each existing message beside its replacement.

Select the green rewrite button in the toolbar.

You'll see the Review message changes dialog. Each edited commit has an Original column beside a Proposed column.

Compare every proposed message with its original message.
Select Keep editing if any proposed message needs another change.

What happens during the rewrite?

The tool creates the backup branch before it updates the current branch. It starts rebuilding history from the earliest commit you edited.

File contents stay unchanged. Author information and commit dates also stay intact.

Submit the rewrite

Submitting a history rewrite can feel final. Your original practice history remains available on the timestamped backup branch created during this action.

Before you confirm, what should the completion status mention if the safety copy was created?

Select Back up & rewrite in the review dialog.

Once the rewrite finishes, you'll see Rewrite complete. Backup branch: followed by the timestamped branch name. The pending-edit counter returns to 0 pending edits.

That's the risky part handled. Your practice branch now carries the cleaner messages while the backup branch preserves the original history.

Rewrite did not complete?

Confirm that the pending-edit counter was greater than zero before you opened the review dialog.
Restore a non-empty message in any text area showing a validation warning.
Reload the page if the status area reports a lost connection.

Ask for help with the exact status shown in your browser: Help me diagnose why commit-rewriter did not complete my local history rewrite.

Your practice messages are clean and the original history has a safe home. Next, you'll compare both histories to see exactly what the rewrite changed.

Compare the Rewritten History

The local editor has rewritten your throwaway Git repository. Your current branch now carries the clear messages you submitted in the browser.

A commit hash identifies a commit's exact contents. Editing an earlier message changes that hash.

Every later hash after that point changes too because each commit records its parent. The side-by-side comparison makes that chain visible before you work on your real repository.

In this step, get ready to:

Read the rewritten commit log.
Locate the timestamped backup branch.
Compare the original history with the rewritten history.

Read the rewritten log

The current branch represents the version you would keep. Its log should now read clearly from top to bottom.

Switch back to the terminal from earlier.
Display the rewritten current branch by running this command:

git log --oneline

What does this command show?

The --oneline option places a shortened commit hash beside each message.
The newest commit appears first.

You should see the cleaner messages you submitted. Each message has a shortened hash on its left.

Still Seeing the Messy Messages?

Check that the terminal is inside the throwaway repository from earlier.
Confirm that you submitted the edited messages in the browser editor.

Still stuck? Help me find why the rewritten messages are missing from my Git log.

Find the backup branch

The editor preserved the original history on a timestamped backup branch. Locating that branch confirms that the old messages remain available for comparison.

List the local branches by running this command:

git branch --list

What does this command show?

The --list option shows the local branches in this repository.
An asterisk marks the current branch.

You should see your current branch marked with *. You should also see a second branch with a timestamp in its name.

You have found the branch that keeps the original history within reach.

Record the timestamped backup branch name here: your timestamped backup branch name.

Backup Branch Missing?

Confirm that the branch list belongs to the throwaway repository.
Check the browser editor from earlier for confirmation that the rewrite finished.

Need another pair of eyes? Help me locate the backup branch created during my history rewrite.

Compare both histories

The current branch points to the rewritten commits. The backup branch points to the original commits from before the browser submission.

Before you run the comparison, do you expect only the commits with edited messages to receive new hashes?

Display every branch as a compact commit graph by running this command:

git log --oneline --decorate --graph --all

How does this comparison work?

The --all option includes every branch reference in the log.
The --decorate option adds branch names beside the commits they reference.
The --graph option draws the paths through the commit history.
The --oneline option keeps each commit compact.

Compare the clear messages on the branch marked HEAD with the original messages on your timestamped backup branch name.
Compare the shortened hashes beside matching commits.

You'll see the branch marked HEAD follow a different path from your timestamped backup branch name. The current path carries clear messages with new hashes.

The backup path carries the original messages with their original hashes. Commits after the earliest edited commit also have different hashes.

Why Did the Later Hashes Change?

Each commit records its message plus the hash of its parent. Changing one message produces a new hash for that commit.

The next commit now records a different parent hash. The effect continues through every later commit.

Cannot See Two Histories?

Confirm that the timestamped backup branch still appears in the branch list.
Check that the graph command includes --all.

Need help reading the graph? Help me understand why my rewritten branch and backup branch are not both visible.

That's the surprise made visible: cleaner messages produced a new chain of commit hashes while the backup preserved the old one. Next up, you'll repeat this carefully on your own repository using a separate branch.

Rewrite a Branch in Your Repo

Your throwaway repository proved that a cleaner message creates a new commit hash. Its backup branch kept the original history available.

A real repository raises the stakes because its history may already matter to other people. You will perform the rewrite on a dedicated Git branch. You will keep the original history in a local backup before publishing the result.

In this step, get ready to:

Create a dedicated branch for the real repository rewrite.
Rewrite selected commit messages one at a time.
Verify the backup before pushing the rewritten branch.

Prepare a dedicated rewrite branch

A dedicated branch keeps the rewritten history separate from the branch other people may use. This makes the first push a new remote branch.

Set your real repository location to path to your real repository.
Move into that repository by running this command:

cd "[[REAL_REPO_PATH="path to your real repository"]]"

What does this command do?

The command moves your terminal into the real repository you identified earlier. Every following command now acts on that repository.

Check the repository for uncommitted work by running this command:

git status

Why check the working tree?

The status output shows files that differ from the current commit. Continue when it confirms that your working tree is clean.

Rewriting real history can feel risky. A clean working tree plus a dedicated branch keeps your current file changes out of the operation.

Commit or store any uncommitted work before continuing.
Choose a dedicated branch name: commit-message-cleanup.
Create the dedicated branch by running this command:

git switch -c [[REWRITE_BRANCH="commit-message-cleanup"]]

How does the branch protect your repo?

The command creates a branch at your current commit. It also switches your working tree to that branch.

The original branch stays pointed at the existing history. Your rewrite proceeds under a separate branch name.

Confirm the active branch by running this command:

git branch --show-current

What should this show?

The command prints the branch currently checked out. You should see the branch name you chose for the rewrite.

Branch name already exists?

Check your local branch list for the chosen name.
Choose a new branch name if that name already exists.

Still blocked? Help me create a safe branch for rewriting my commit messages.

Rewrite messages one at a time

The commit-rewriter app changes every commit from the earliest edited commit through the branch tip. Editing one message per run gives you a small result to inspect before continuing.

Return to the terminal that served the throwaway repository.
Stop its running process with Ctrl+C if the terminal prompt has not returned.
Switch back to the terminal inside your real repository.
Start the local editor for the current repository by running this command:

uvx commit-rewriter

What happens when the editor starts?

The command runs the editing tool in an isolated environment. The app reads the repository from your current terminal location.

Applying an edit creates a timestamped backup branch before the history changes. That local branch preserves the pre-rewrite commits.

Return to the local editor tab from the throwaway exercise.
Refresh the browser page.
Confirm that the displayed repository path matches your real repository.
Confirm that the displayed branch matches commit-message-cleanup.
Choose one messy commit message to clean up.
Replace that message with a short summary of the change it introduced.

Before you submit the edit, which commits do you expect to receive new hashes?

Select Rewrite commit messages.

The app rewrites the selected commit plus every descendant on the branch. The file contents remain unchanged.

Return to the terminal inside your real repository.
Find the new timestamped backup branch by running this command:

git branch

What does the branch list prove?

The branch list includes your active rewrite branch plus the timestamped branch created by the app. That new branch points to the history from before your first real rewrite.

Record the first timestamped backup branch as your first timestamped backup branch.
Inspect the rewritten message by running this command:

git log --oneline

What does the log confirm?

The compact log pairs each abbreviated hash with its commit message. You should see your cleaner message next to a new hash.

That is your first real rewrite complete. You checked its result before touching another message.

Return to the local editor in your browser.
Refresh the page to load the rewritten history.
Choose the next messy commit message.
Replace it with a clear summary of its actual change.
Select Rewrite commit messages.
Use the same one-message cycle for one more commit if your branch has a third messy message.

Verify and push the rewritten branch

Your rewritten log needs one final comparison against the first backup. This confirms that the messages changed while the original history stayed reachable.

Pushing is the point where your rewrite leaves your laptop. Your dedicated branch publishes the cleaned history without replacing the shared branch on the remote.

Before you compare the logs, where do you expect to see the old messages?

Compare the rewritten history with the original history by running these commands:

git log --oneline
git log --oneline [[BACKUP_BRANCH="your first timestamped backup branch"]]

How do these logs differ?

The first command reads the current rewrite branch. Its selected messages should be clear.
The second command reads the first timestamped backup branch. Its original messages should still be present.
The hashes differ from the earliest edited commit through the branch tip. Each rewritten commit is a new Git object.

List the repository remotes by running this command:

git remote -v

Which remote should you use?

The output lists the remote names plus their fetch and push locations. Choose the remote where you have permission to create the rewritten branch.

Record that remote as your push remote.

Before you push, do you expect the remote to create a new branch or replace an existing branch?

Publish the rewritten branch by running this command:

git push -u [[REMOTE_NAME="your push remote"]] [[REWRITE_BRANCH="commit-message-cleanup"]]

What does this push do?

The command sends the rewritten branch to your chosen remote. The upstream setting connects your local branch to the new remote branch.

The timestamped backup branch stays local because you did not include it in the push. Keep it until you are satisfied with the published history.

You have completed the real-world rewrite safely. The cleaned branch is now available on the remote while the original history remains on your laptop.

Confirm that the rewritten branch tracks a remote branch by running this command:

git branch -vv

What should the branch details show?

The active branch should display tracking information for your chosen remote. Its latest abbreviated hash should match the first entry in your rewritten log.

Push did not complete?

Check that the selected remote matches the repository you own.
Complete any authentication prompt from your Git hosting provider.
Avoid forcing the rewrite over a remote branch that other people use.

Need a hand? Help me troubleshoot why my rewritten Git branch will not push.

Your real repository now has a publishable commit log on its own remote branch. Both local backup repositories remain available if you need to inspect the original histories.

Secret mission

Map the Rewrite Blast Radius

Trace exactly how one edited message changed the hashes that followed it. Then create a handoff note covering the rewritten branch plus its local backup. Your note gives collaborators the context they need before they continue working.

Clean Up Your Resources

Your commit rewrite ran through a local web app, so it creates no ongoing service costs. Choose whether to keep the backup history, pause with everything preserved, or delete the cleanup resources.

Resources you used:

The real repository backup branch in your Git repository, which preserves the pre-rewrite commit history.
The throwaway repository, which contains its rewritten current branch and timestamped backup branch.

Keep everything running

No action needed. Choose this if you want both backup histories available while you review the rewritten commit messages.

Keep the real repository backup branch until you are confident that the rewritten history is correct.
Use the throwaway repository as a reference for comparing original commit hashes with rewritten hashes.
Leave the rewritten real repository branch on its remote so the cleaned commit log remains available.

Pause - I'll come back to this later

Pausing means ending any remaining local web app process while keeping both repositories unchanged. Your backup histories remain available for another comparison.

End the local web app process if it is still active.
Keep the real repository backup branch until you finish reviewing the rewritten history.
Keep the throwaway repository with both of its branches intact.
Return to the log comparison from earlier when you resume.

Delete - I don't want to use this again

Remove the practice repository once you understand the hash changes. Delete the real repository backup branch only after the rewritten commit log is exactly what you want.

Check Before You Delete

The real repository backup branch preserves the pre-rewrite history created by the tool. Deleting it removes that local recovery copy.

Your pushed rewritten branch stays on the remote.

Return to the real repository from earlier in your terminal.
Compare the rewritten branch history with the timestamped backup branch one final time.
Use Git's local branch deletion operation to delete the timestamped backup branch.
Confirm the timestamped backup branch no longer appears in the local branch list.
Locate the throwaway repository folder from earlier in your operating system's file browser.
Move the throwaway repository folder to your system's deleted-items location.
Confirm the throwaway repository folder no longer appears in its original location.

Cleanup Still Showing?

If the branch remains listed, check that you targeted the timestamped backup branch instead of the rewritten branch. Get help deleting the local backup branch safely.

If the file browser cannot remove the throwaway repository folder, end any process that is using it. Try the deletion again.

Nice Work!

You did it! Your repo now has a clean commit log backed by a timestamped branch that preserves the original history.

You've learned how to:

Tested a Git history rewrite in a throwaway repo. A timestamped backup branch preserved the original commits.
Cleaned commit messages through a local web app. Compared the rewritten log with the backup branch to see how later commit hashes changed.
Repeated the rewrite one message at a time in a real repo you own. Pushed the rewritten branch to its remote.
Secret Mission: Took on an optional challenge to push your history-rewriting skills further.

Ready to quiz yourself?