Chapter 10. Altering Commits
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 12, 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.
Get Version Control with Git, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
