▲ | iandanforth 3 days ago | ||||||||||||||||||||||
Can I suggest, don't do this? The sustainable unit of code modification is the ticket, not the commit. When you're ready to merge to main, squash all commits into one that takes the ticket title as its commit message and appends the ticket description as its description. This aligns code changes with planned, scoped, and documented units of work. Anything more granular than that quickly becomes noise. By following the above pattern your main commit history becomes a clean, consistent log of tickets being completed, each linking directly back to your ticket management system. | |||||||||||||||||||||||
▲ | Fire-Dragon-DoL 3 days ago | parent | next [-] | ||||||||||||||||||||||
I don't get it. Assuming your commits have meaningful messages and description, why squashing them? You can use git log --merges-only (I think that's the arg name) and all the sub commit are hidden, however you can still search through them to get a clear idea of why something was refactored a certain way. So,where is the noise if it can be hidden but also used to get additional information on code changes? | |||||||||||||||||||||||
| |||||||||||||||||||||||
▲ | CityOfThrowaway 3 days ago | parent | prev | next [-] | ||||||||||||||||||||||
The best practice that I've seen done (and enjoy) is: 1. Always squash and merge 2. But have tidy commits 3. So your squashed commit has a useful list of what is in the commit | |||||||||||||||||||||||
▲ | collingreen 3 days ago | parent | prev | next [-] | ||||||||||||||||||||||
I don't agree with most of this but my good faith take is that my experience trends closer to your opinion the more stable and large a codebase is plus how dedicated and multidisciplinary the team is. I disagree the most for young, volatile projects with small eng-only teams that are responsible for many projects at once. | |||||||||||||||||||||||
▲ | bredren 3 days ago | parent | prev [-] | ||||||||||||||||||||||
This project seems focused on preparing branches for review by giving them clearly communicated commit histories. I think the intent is that it be up to the org to decide whether they’ll accept a stream of commits to merge or squash merge after approval. |