4 ms·

Why not preserve full commit history in feature branches, iterate with code reviews on pull requests, then squash when merging to an integration branch? This wa

• Androider 10y ago
  That is exactly what I do, even if working on a project by myself. My feature development branch will have a commit for each logical change, typically 3-5/day done by staging individual chunks with "git add -p" (exclusively) as a "I'm done with this piece" checkpoint, still leaving all debug and still in-progress parts in my working copy only. But I wouldn't hesitate to do a "I'm moving from my laptop to my desktop" work-in-progress commit either. Later commits will frequently undo changes done in earlier feature commits, or just revert a commit outright if it proved to go down the wrong development path. You really can't commit too often in my opinion, and it's incredibly freeing knowing you can make sweeping changes and then back out of them at a moments notice. For merging, I will rebase on master, squash everything into 1 or a few logical commits, and _review_ the resulting commit diff manually as if I were to send it to a maintainer. I will write an extensive commit message based on the code review as a kindness to my future self. The development branch still exists and can be referred to at any time, but I don't want to see that cruft when looking at the project log.