A commit records the history of your work and keeps your changes sacrosanct, but the commit itself isn’t cast in stone. Git provides several tools and commands specifically designed to help you modify and improve the commit history cataloged within your repository.
There are many valid reasons why you might modify or rework a commit or your overall commit sequence:
You can fix a problem before it becomes a legacy.
You can decompose a large, sweeping change into a number of small, thematic commits. Conversely, you can combine individual changes into a larger commit.
You can incorporate review feedback and suggestions.
You can reorder commits into a sequence that doesn’t break a build requirement.
You can order commits into a more logical sequence.
You can remove debug code committed accidentally.
As you’ll see in Chapter 11, which explains how to share a repository, there are many more reasons to change commits prior to publishing your repository.
In general, you should feel empowered to alter a commit or a commit sequence if your effort makes it cleaner and more understandable. Of course, as with all of software development, there is a trade-off between repeated overrefinement and acceptance of something that is satisfactory. You should strive for clean, well-structured patches that have concise meaning for both you and your collaborators. However, there comes a time when good enough is good enough.
As a general guideline, you should feel free to alter and improve your repository commit history as long as no other developer[22] has obtained a copy of your repository. Or, to be more pedantic, you can alter a specific branch of your repository as long as no one has a copy of that branch. The notion to keep in mind is that you shouldn’t rewrite, alter, or change any part of a branch that’s been made available and might be present in a different repository.
For example, let’s say you’ve worked on your
master branch and made commits A
through D available to another developer, as shown in
Figure 10-1. Once you make your
development history available to another developer, that chronicle is
known as a published history.
Let’s say you then do further development and produce new commits
W through Z as unpublished history
on the same branch. This is pictured in Figure 10-2.
In this situation, you should be very careful to leave commits
earlier than W alone. However, until you republish
your master branch, there is no reason you can’t
modify the commits W through Z,
including reordering, combining, and removing one or more commits, or,
obviously, adding even more commits as new development.
You might end up with a new and improved commit history, as
depicted in Figure 10-3. In this
example, commits X and Y have been
combined into one new commit; commit W has been
slightly altered to yield a new, similar commit W';
commit Z has been moved earlier in the history; and
new commit P has been introduced.
This chapter explores techniques to help you alter and improve your commit history. It is for you to judge whether the new history is better, when the history is good enough, and when the history is ready to be published.