Information Technology Reference
In-Depth Information
CHAPTER 8
Modifying the History
This chapter deals with the diverse commands that modify the structure of the revision
graph. Sometimes you will need to merge three different revisions into one revision. At
other times you may need the opposite operation: splitting a single commit into many
separate commits. Whatever the case may be, keep in mind that git revisions are per-
manent. They never change. Once you have created a revision, there is no way to modi-
fy it. All you can do is to throw it away using the method presented in Recipes 3-12 and
5-4. Therefore, whenever I say something like “let's modify a revision,” the operation I
have in mind is to create a new revision that will resemble the original one. The original
revision remains unchanged in the git database. It can be inaccessible through symbolic
references other than reflog, but it is still there. Until the next database purging, that is.
If any of the operations produce results that you find unsatisfactory, you can always
return to the previous state. All you need is the name of the revision that contains the
correct snapshot. You can use reflog to find this name, but you can also create a tempor-
ary branch that will preserve the reference to the desired revisions. Because the revisions
do not change, you don't need to worry about the consequences of modifying the revi-
sions. Whatever you do, you will never change the revisions that are already stored in
the database. Committing, rebasing, and merging only produce new revisions—these op-
erations do not modify the existing revisions. It's impossible to modify a revision.
This was a real breakthrough for me in my study of git. Once I learned how to re-
structure the graph of revisions and how to undo various operations, I gained the confid-
ence that allowed me to freely use the tool.
8-1. Amending the most recent revision
