How to add a changed file to an older (not last) commit in Git

Use git rebase. Specifically:

1. Use git stash to store the changes you want to add.
2. Use git rebase -i HEAD~10 (or however many commits back you want to see). Alternatively, use git rebase -i commitHash^. Replace commitHash with the hash of the commit you want to edit, which you can get by git log
3. Mark the commit in question (a0865...) for edit by changing the word pick at the start of the line into edit. Don't delete the other lines as that would delete the commits.[^vimnote]
4. Save the rebase file, and git will drop back to the shell and wait for you to fix that commit.
5. Pop the stash by using git stash pop.
6. Add your file with git add <file>.
7. Amend the commit with git commit --amend --no-edit.
8. Do a git rebase --continue which will rewrite the rest of your commits against the new one.
9. Repeat from step 2 onwards if you have marked more than one commit for edit.
10. If you have previously pushed the modified commits anywhere else, then you will have to push --force again to update them on the remote. However, the usual warnings about using --force apply, and you can easily lose other people's work if you are not careful and coordinate with them beforehand.

[^vimnote]: If you are using vim then you will have to hit the Insert key to edit, then Esc and type in :wq to save the file, quit the editor, and apply the changes. Alternatively, you can configure a user-friendly git commit editor with git config --global core.editor "nano".

To "fix" an old commit with a small change, without changing the commit message of the old commit, where OLDCOMMIT is something like 091b73a:

git add <my fixed files>
git commit --fixup=OLDCOMMIT
git rebase --interactive --autosquash OLDCOMMIT^

You can also use git commit --squash=OLDCOMMIT to edit the old commit message during rebase.

See documentation for git commit and git rebase. As always, when rewriting git history, you should only fixup or squash commits you have not yet published to anyone else (including random internet users and build servers).

Detailed explanation

• git commit --fixup=OLDCOMMIT copies the OLDCOMMIT commit message and automatically prefixes fixup! so it can be put in the correct order during interactive rebase. (--squash=OLDCOMMIT does the same but prefixes squash!.)
• git rebase --interactive will bring up a text editor (which can be configured) to confirm (or edit) the rebase instruction sequence. There is info for rebase instruction changes in the file; just save and quit the editor (:wq in vim) to continue with the rebase.
• --autosquash will automatically put any --fixup=OLDCOMMIT commits in the correct order. Note that --autosquash is only valid when the --interactive option is used.
• The ^ in OLDCOMMIT^ means it's a reference to the commit just before OLDCOMMIT. (OLDCOMMIT^ is the first parent of OLDCOMMIT.)

Optional automation

The above steps are good for verification and/or modifying the rebase instruction sequence, but it's also possible to skip/automate the interactive rebase text editor by:

• Setting GIT_SEQUENCE_EDITOR to a script.
• Creating a git alias to automatically autosquash all queued fixups.
• Creating a git alias to automatically fixup a single commit.

with git 1.7, there's a really easy way using git rebase:

stage your files:

git add $files

create a new commit and re-use commit message of your "broken" commit

git commit -c master~4

prepend fixup! in the subject line (or squash! if you want to edit commit (message)):

fixup! Factored out some common XPath Operations

use git rebase -i --autosquash to fixup your commit

You can try a rebase --interactive session to amend your old commit (provided you did not already push those commits to another repo).

Sometimes the thing fixed in b.2. cannot be amended to the not-quite perfect commit it fixes, because that commit is buried deeply in a patch series.
That is exactly what interactive rebase is for: use it after plenty of "a"s and "b"s, by rearranging and editing commits, and squashing multiple commits into one.

Start it with the last commit you want to retain as-is:

git rebase -i <after-this-commit>

An editor will be fired up with all the commits in your current branch (ignoring merge commits), which come after the given commit.
You can reorder the commits in this list to your heart's content, and you can remove them. The list looks more or less like this:

pick deadbee The oneline of this commit
pick fa1afe1 The oneline of the next commit
...

The oneline descriptions are purely for your pleasure; git rebase will not look at them but at the commit names ("deadbee" and "fa1afe1" in this example), so do not delete or edit the names.

By replacing the command "pick" with the command "edit", you can tell git rebase to stop after applying that commit, so that you can edit the files and/or the commit message, amend the commit, and continue rebasing.

Here's a function that implements @Greg's answer:

function gitamendoldcommit() {
 printf "\n\nPress any key if you have no changes other than those you want to add to 1ドル."
 printf "(You can commit your unwanted changes and undo later.):\n\n"
 read foo
 printf "\n\nChange 'pick' to 'edit' in front of 1ドル (top one), save, close the editor & press any key..."
 printf "Resolve any possible conflicts, if any. then: git add .; git rebase --continue\n\n"
 git rebase -i 1ドル^
 git stash pop
 git add .
 git commit --amend --no-edit
 git rebase --continue
}

Usage: (while having only the intended changes in the staging) gitamendoldcommit $OLDCOMMIT

Aditionally, if you use git rebase -i and want to go to the first commit of your current branch you can use git rebase -i --root. Now you could easily modify your first commit.

Based on the marked answer the best way to do file changes on an old commit, not the previous one, is git rebase interactive. But instead of using HEAD~NUMBER I prefer to use hash commits. So my answer is like the following example, I want to change the getRandomArbitrary.ts which I wrote many commits ago:

1. git log: I run this command and then find the commit which I want to edit, and get the previous hash commit:

   git log

2. git rebase -i COPIED_HASH_COMMIT: By running this command, Git will show me a list of commit messages, I modify the one I want to edit, only change the pick word to edit and save the list:

   git rebase interactive

3. Now it's time to edit. The git history goes back to when the getRandomArbitrary.ts file was generated (it's like a time machine - change the future 😁)

4. After the modification, I should save the git history and turn it back to the latest, by running git add <file> and then git rebase --continue it does exactly what I want.

HINT: I changed the git history so that up-stream will reject git push. I must run git push -f to do a force push (only this time).

In 2023 there are tools that do this: specifically git absorb. It is a great tool with the potential to change a lot of dusty git workflows.

• git
• git-rebase