[iandanforth]

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]

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?

[dakiol]

In my experience, when people need to know what commit belongs to what code, is the IDE the main driver: you see the line of code in the editor and automatically know what commit introduced it (e.g., via the git integration in the gutter). Typically you want to know as well all the other lines of code that were committed together (e.g., what does it take to implement feature X? Ah yeah, all these changes).

I couldn’t care less what changes were introduced in a particular commit (what for? Debugging? Your features should be small enough that debugging them shouldn’t be a pita anyway)

[baq]

If you need to use —-merges-only you might as well squash everything, why bother.

[Fire-Dragon-DoL]

I use merges-only when I need to look at the history "index" and I use the full history when I need to find out why a certain line was changed, kinda like a book has an index but there are also all the chapters with all the content

[CityOfThrowaway]

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]

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]

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.