I’m wondering what the best/standard practices are for maintaining a project’s git history. I’ve been improving my efforts to have a clean, simple commit history, but eventually the history will get to be pretty long if it goes back to the project’s very first commit (I’m thinking for projects operating for years to decades or more, or in my present case, from old projects when I was first learning to use git and didn’t use squash commits and have lots of long commit messages). Does the git history ever get archived, squashed, or removed, or is project history expected to stick around in perpetuity (like, can I see Python 1.0’s very first commit?). I try hard to keep on top of digital clutter, and this seems like something getting into that category, especially for older projects, but I don’t want to remove an archived repo’s git history if that’s considered bad practice.
For reference, here are the first few commits for Python, with the initial commit dated 1990-08-09:
I think the git history is never actively archived, squashed or modified in any other way.
In our maintenance (and other) projects we follow team-defined standards for git messages:
- Link a unique issue key: This helps to understand solutions when analyzing code because of bugs or unexpected behaviour
- In one sentence tell (imperatively) what this commit does: This helps having a concise and consistent history
- Syntax and orthographics matter! Writing proper messages without typos, correct punctuation and gramatically correct structures supports readability and gives an overall feeling of quality.
I’d strongly suggest not to change anything in your git history. Removing parts of the history removes a lot of context information that could be relevant when working on a specific part of your system.
Does this help you?
Thanks @jthetzel and @keniseli! It sounds like the best practice is to just keep the whole git history, for better or worse, and aim to just make it the best it can be going forward. Thanks for this advice. : )
Commit message style is a personal or project preference. However, Conventional Commits has codified useful best practices.
URL encoding appers to mangle the link. It should be:
https://github.com/python/cpython/commits/master?after=344dce312a0cf86d5a5772d54843cc179acaf6e3+107760
But here’s the first Python commit:
FWIW. I think the hardest part for me about writing good commits is my disorganized development approach. If you actually plan/chunk the work to occur in “commit” sized pieces, then the commit description will be easy to write. And the history will be much more useful.For example, it’s much easier to undo a bug if it isn’t lumped into one commit with unrelated code. Conversely it’s not easy to write a good commit message for a random set of unrelated changes.
But yah. The history will probably stick around. It’s nice in case you want to blame a colleague for a bug they introduced months back.