Git public vs private history
Have you ever read that you should never change git commit history? This seems to be a common admonition in many Git tutorials, at least from my reading. But this also begs the questions: “Why not?” and “When should git history be changed? I’ve asked these questions myself, and found some use cases where modifying commit history is smart, and sometimes vital.
(Any time I read “You should do…” or not do something, I want to know why.)
Now, suppose as a matter of good engineering stewardship, every git commit shipped to production records a meaningful increment of change. That is, every commit on the production branch should deliver business value. It’s not difficult to further ask each commit to also pass all the tests, security standards, code quality requirements, and the like.
How can this be achieved?
The key is drawing a line between private commit history and public commit history:
Private git history
- Everything which is local to anyone’s development computer, particularly which has not pushed for public examination.
- Unmerged code in remote repositories with a single contributor.
Public git history
- Master/Main/Trunk, or whatever the specific branch is named which is promoted to production.
- Shared, long running branches with contributions from multiple developers. However, as noted in Accelerate, long running branches are correlated with low performing teams.
The key point: a git repository’s public history can be managed as an asset. Private git history integrated into the production branch may become a liability over time, the complexity induces semantic overload.
Achieving this state requires a bit of git mastery, none of which is very difficult, and will be covered in a future article.