I really like the idea of rebasing because it gives you a much easier-to-parse revision history (assuming you enforce good commit messages, structure, etc). Th

I really like the idea of rebasing because it gives you a much easier-to-parse revision history (assuming you enforce good commit messages, structure, etc). The problem I have with it though is early development. The history can be a total mess since lots of things are changing quickly. I often feel like it's not worth the effort of good commit discipline so early on, but once we get to an alpha or beta state, I find myself wishing we had a clean commit history where every commit on main passes CI (which may not have existed in the early commits). Does anyone have suggestions on how to address this? The two easy answers that come to mind are 1) squash everything into an "initial commit" once possible, or 2) just don't worry about old commits passing CI. What I've ended up doing is rewriting the history to move everything on main to a "legacy" branch and have a single merge commit start what ends up being the production version of main. Even with a script, it's still error prone and a little scary to me...