Git and Historical Revision
A well crafted history is a trade off. It's similar to writing tests. Most of the time tests do nothing, but when they raise an alarm it is super handy. With practice, the cost is minimal.
Every extra flourish, every extra care we put into the products of our labor is always met with the criticism of "how does this impact the bottom line."
A well-crafted history is a trade-off. It's similar to writing tests. Most of the time tests do nothing, but when they raise an alarm it is super handy. With practice, the cost is minimal. Let's look at an example.
Imagine if you added a new section to the "My Account" part of your web app and it didn't work right. Your pull request had 8 commits that merged into your main git branch. Some of the code you wrote was a refactor and someone has already built new features on top of your refactor.
To fix this situation we would have to try to reimplement the refactor, or possibly comment out bits of code. It'll take a while and the confidence level might be low, especially if the code wasn't covered well with tests. If you had rebased your 8 commits into possibly 3 commits:
- A code-cleanup commit.
- A refactor of the underlying code.
- Your actual deliverable including documentation and the automated tests.
Removing your buggy code would be short work.
Not every pull request needs to be broken down into these three types of commits. In fact, you can even say that each of these 3 steps warrants it's own pull request.
Any time you do a "rebase" to edit your history it can often create brand new SHAs in your timeline. So if you push your feature branch back to Github or anywhere else you'll have to do a --force push. E.g. git push -f origin my-feature-branch.