[lysp]

That's why I prefer feature branches with merge commits.

Your dev branch is clean because each merge-commit is a single commit per task.

So you can see which tasks were merged and in which order and what file as a whole were changed in each task.

If for debugging / code review or any other reason need to look at specifics, you can look through the feature branch commit by commit to see what was changed and why.

It's best of both worlds.

Similarly merging dev into master/main. You get a release by release view of what files were changed in a single merge commit.

[rvdginste]

Completely agree with parent and grand-parent. For me, a nice clean commit history is an investment in future maintenance.

Following the rules described above means that you get a lot of context on why code was changed:

* the invidivual commit which should contain a description of the change if the change is not self explanatory or not 'intuitive', the individual commit should consist of only 1 functional change

* the commits surrounding it, the feature branch (clearly visible because of the merge commits)

* the issue number on the commit itself and possibly in the merge commit

I've found all this context very informative for projects that are in maintenance mode and still need changes from time to time. Obviously, the higher the quality of the commit history, the higher the quality of the information you get out of it.

Meaning: if you put a rename with an impact over the whole code base (because the original name just happened to bother you that day) together with a bugfix in the same commit and the commit message has the very informative text 'fix', and the referenced issue mentions 'add support for blah' (but the commit obviously does not implement anything related to 'blah'), then... well, yeah, then how you organise your commit history does not really matter.

[lysp]

* the issue number on the commit itself and possibly in the merge commit

Absolutely this too!

My process is to create a feature branch named "ISSUE-123-issue-description"

The benefit of this is all changes are tracked (and tested) against a specific issue in bug management software.

It also prevents people making small / unrelated changes or fixes in association with another task. If these are grouped in together in a single and unrelated task they won't be trackable or testable.

[infogulch]

The merge commit always refers back to the PR id, so even if it was squashed you can still look up the play-by-play by looking up the PR. I wonder if this could be represented in git by tagging the squashed branch with the PR id with a description that has the merge commit id, and the merge commit description that references the tag. It would be nice if something like this could be standardized so it works across systems.