Part 7
Fixing Things

As we discussed earlier, Git breaks the process of committing a change and sharing that same change into two separate processes. The benefit of that separation comes into sharp focus when you need to fix something.

Every commit in Git can be changed. You should avoid making changes to commits you’ve shared to avoid potential conflicts with other developers. Keeping that in mind, you can adjust commits as much as you want.

Covered in this part:

• You need to fix a typo, you forgot to run the unit tests before committing and accidentally broke them, or you found a bug after the commit. You learn how to fix these issues in Task 35, ​Fixing Commits​.

• You can undo a commit after you’ve shared your changes by reverting it—applying the reverse of a commit as a new commit. You learn how to do this in Task 36, ​Reverting Commits​.

• You can reset your current HEAD to any other commit in the repository and start working from there. In practice, it’s most useful to undo one or more of the most recent commits. We cover this in Task 37, ​Resetting Staged Changes and Commits​.

• Sometimes you don’t need to fix a commit; you need to remove it entirely. You learn how to do that in Task 38, ​Erasing Commits​.

• Fixing and removing commits is the easy part. Most issues are bugs in your code. Git provides an excellent tool for isolating the commit (or commits) that introduced a bug. You learn about it in Task 39, ​Finding Bugs with bisect​.

• Finally, all of this rewriting can cause issues if you’re not careful. One of Git’s mandates is to not lose code, though, so it provides the reflog to help you recover. You learn how to navigate it in Task 40, ​Retrieving “Lost” Commits​.