In the world of software development and version control, Git stands as an indispensable tool. Developers often find themselves in situations where a past commit, perhaps made in haste, needs a crucial modification. Whether it’s a forgotten file, a minor typo in a commit message, or a small logical fix that truly belongs with an earlier change, the ability to easily fix up a past commit is a powerful skill. While Git encourages a linear history, it also provides robust mechanisms to refine and clean up your work before sharing it with the wider team. Mastering these techniques ensures your project history remains clear, concise, and professional, making collaboration smoother and debugging efforts more straightforward.

Understanding Git’s Immutability and the Need for Refinement

At its core, Git treats commits as immutable snapshots of your project at a specific point in time. Each commit has a unique SHA-1 hash, acting as its permanent identifier. This immutability is fundamental to Git’s integrity, ensuring that once a commit is made, its content cannot be casually altered without changing its hash and, by extension, the history that follows it. However, the reality of development is iterative and often messy. We sometimes commit too early, forget to include a file, or make a minor correction that logically belongs with a previous, larger change.

This is where the concept of “rewriting history” comes into play. While the term might sound daunting, it refers to powerful Git commands that allow you to refine your local commit history before pushing it to a shared remote repository. The goal isn’t to erase history but to present a cleaner, more logical narrative of your project’s evolution. This refinement helps in several ways:

• It makes code reviews more efficient by grouping related changes.
• It simplifies debugging, as commit messages accurately reflect the changes within them.
• It keeps the project history tidy, which is crucial for long-term maintenance.

The most common scenario requiring a fix-up is when you’ve committed a feature, then immediately realized you missed a small part or made a minor bug that’s intrinsically tied to that feature. Rather than creating a separate “fix” commit, it’s often cleaner to integrate that fix directly into the original commit, presenting a single, cohesive change.

The Power of git rebase --interactive for Fixups

The primary tool for modifying past commits is git rebase --interactive (often shortened to git rebase -i). This command allows you to view and modify a sequence of commits. When you initiate an interactive rebase, Git opens an editor displaying the commits you’ve selected, each prefixed with a command (like pick). This is your staging ground for history manipulation.

Among the various commands available in an interactive rebase, fixup (or f) and squash (or s) are specifically designed for combining commits. The fixup command is particularly useful when you want to merge a newer commit’s changes into an older one, completely discarding the newer commit’s message. This is ideal for small corrections or forgotten files that logically belong to a previous commit, without cluttering the commit history with trivial messages.

For instance, if you have commit A, then commit B (a small correction for A), and you want to merge B into A, you would use fixup. The resulting commit would have A’s message and A’s content, plus B’s content. This method helps maintain a clean, readable commit log, crucial for team collaboration and future auditing. According to Atlassian’s Git tutorials, “Interactive rebasing is one of the most powerful features Git has for cleaning up your commit history, allowing you to rewrite, reorder, and combine commits.” Source.

Step-by-Step: Fixing a Past Commit with git fixup

Here’s a practical guide on how to use git fixup to merge changes into a prior commit:

1. Identify the Target Commit: Determine which past commit you want to modify. Let’s say it’s the Nth commit from your current HEAD. You’ll need to rebase up to the commit before your target commit. For example, to fix the 3rd commit back, you’d rebase on HEAD~4 (or SHA-of-commit-before-target).
2. Create the Fixup Commit: Make your changes and stage them using git add .. Then, create a new commit with the --fixup flag, referencing the SHA of the target commit you want to fix. For example: git commit --fixup <SHA_of_target_commit>. This special commit will be marked for automatic squashing/fixing during the rebase.
3. Start the Interactive Rebase: Run git rebase -i <SHA_of_commit_before_target> (or HEAD~N where N is the number of commits from HEAD you want to include in the rebase, plus one).
4. Reorder and Mark for Fixup: In the editor that opens, you’ll see a list of commits. Move your newly created fixup! commit directly below the target commit you want it to modify. Then, change the action for your fixup! commit from pick to fixup (or just f). Ensure the target commit remains pick.
5. Save and Exit: Save the file and close your editor. Git will then apply the rebase, merging your fixup commit’s changes into the target commit and discarding the fixup commit’s message.

This process effectively rewrites the history, replacing the original target commit with a new one that includes your fixed changes. It’s crucial to remember that this alters commit SHAs, which can impact collaborators if you’ve already pushed these commits to a shared branch.

The ability to fix up a past commit is incredibly versatile and applies to several common development scenarios, leading to a much cleaner and more professional commit history. This is particularly valuable when preparing a feature branch for merging into a main branch or for code review.

One frequent scenario is when you’ve committed a new feature, only to realize moments later that you forgot to include a small but essential configuration file or a single line of code. Instead of creating a new commit titled “Forgot file” or “Small fix,” which clutters the history, you can simply add the forgotten item, stage it, and use git commit --fixup <original_commit_SHA>. Then, an interactive rebase will effortlessly merge it into the original feature commit, making it appear as if it was always part of that commit. This approach maintains the logical integrity of your changes.

Another common use case is correcting a typo or refining the wording within a commit message of a non-head commit. While git commit --amend is perfect for the very last commit, for older commits, an interactive rebase is necessary. You would initiate a rebase, find the commit with the typo, change its action from pick to reword (or r), and Git will pause during the rebase to allow you to edit the message. This ensures your commit log is not only functionally accurate but also grammatically correct and clear.

Finally, consider the situation where you have several small, sequential commits that, in retrospect, should have been a single, logical unit. Perhaps you committed a function, then another commit for its tests, and a third for its documentation. With git rebase -i, you can use the squash command (which combines changes and lets you edit the combined message) or fixup (which discards the secondary messages) to consolidate these into one robust commit. This greatly improves the readability of your project history, making it easier for others (and your future self) to understand the progression of changes. Remember, however, that rewriting history on commits that have already been pushed to a shared branch requires a force push, which should be done with extreme caution and clear communication with your team to avoid conflicts.

Alternative Approaches & Best Practices Question & Answer :

I just read amending a single file in a past commit in git but unfortunately the accepted solution ‘reorders’ the commits, which is not what I want. So here’s my question:

Every now and then, I notice a bug in my code while working on an (unrelated) feature. A quick git blame then reveals that the bug has been introduced a few commits ago (I commit quite a lot, so usually it’s not the most recent commit which introduced the bug). At this point, I usually do this:

git stash # temporarily put my work aside git rebase -i <bad_commit>~1 # rebase one step before the bad commit # mark broken commit for editing vim <affected_sources> # fix the bug git add <affected_sources> # stage fixes git commit -C <bad_commit> # commit fixes using same log message as before git rebase --continue # base all later changes onto this 

However, this happens so often that the above sequence is getting annoying. Especially the ‘interactive rebase’ is boring. Is there any shortcut to the above sequence, which lets me amend an arbitrary commit in the past with the staged changes? I’m perfectly aware that this changes the history, but I’m doing mistakes so often that I’d really love to have something like

vim <affected_sources> # fix bug git add -p <affected_sources> # Mark my 'fixup' hungs for staging git fixup <bad_commit> # amend the specified commit with staged changes, # rebase any successors of bad commit on rewritten # commit. 

Maybe a smart script which can rewrite commits using plumbing tools or so?

UPDATED ANSWER

A while ago, a new --fixup argument was added to git commit which can be used to construct a commit with a log message suitable for git rebase --interactive --autosquash. So the simplest way to fixup a past commit is now:

$ git add ... # Stage a fix $ git commit --fixup=a0b1c2d3 # Perform the commit to fix broken a0b1c2d3 $ git rebase -i --autosquash a0b1c2d3~1 # Now merge fixup commit into broken commit 

ORIGINAL ANSWER

Here’s a little Python script I wrote a while ago which implements this git fixup logic I hoped for in my original question. The script assumes that you staged some changes and then applies those changes to the given commit.

NOTE: This script is Windows-specific; it looks for git.exe and sets the GIT_EDITOR environment variable using set. Adjust this as needed for other operating systems.

Using this script I can implement precisely the ‘fix broken sources, stage fixes, run git fixup <broken_commit>’ workflow I asked for:

#!/usr/bin/env python from subprocess import call import sys # Taken from http://stackoverflow.com/questions/377017/test-if-executable-exists-in python def which(program): import os def is_exe(fpath): return os.path.exists(fpath) and os.access(fpath, os.X_OK) fpath, fname = os.path.split(program) if fpath: if is_exe(program): return program else: for path in os.environ["PATH"].split(os.pathsep): exe_file = os.path.join(path, program) if is_exe(exe_file): return exe_file return None if len(sys.argv) != 2: print "Usage: git fixup <commit>" sys.exit(1) git = which("git.exe") if not git: print "git-fixup: failed to locate git executable" sys.exit(2) broken_commit = sys.argv[1] if call([git, "rev-parse", "--verify", "--quiet", broken_commit]) != 0: print "git-fixup: %s is not a valid commit" % broken_commit sys.exit(3) if call([git, "diff", "--staged", "--quiet"]) == 0: print "git-fixup: cannot fixup past commit; no fix staged." sys.exit(4) if call([git, "diff", "--quiet"]) != 0: print "git-fixup: cannot fixup past commit; working directory must be clean." sys.exit(5) call([git, "commit", "--fixup=" + broken_commit]) call(["set", "GIT_EDITOR=true", "&&", git, "rebase", "-i", "--autosquash", broken_commit + "~1"], shell=True)