kwall@programming.dev to Programming@programming.devEnglish · 2 days agoNo Longer My Favorite Git Commitmtlynch.ioexternal-linkmessage-square19fedilinkarrow-up169arrow-down13
arrow-up166arrow-down1external-linkNo Longer My Favorite Git Commitmtlynch.iokwall@programming.dev to Programming@programming.devEnglish · 2 days agomessage-square19fedilink
minus-squareKissaki@programming.devlinkfedilinkEnglisharrow-up1·edit-21 day agoI’m fine with squash merges for one commit. But otherwise, I consider structuring changes into commits structure too. My team merges with merge commits which hold the MR description as a commit description, and MR title as commit title. Individual commits are retained and can describe individual changes, while the MR and merge commit describe the whole changeset. It’s a very interactive-rebase-heavy workflow (for commit cleanups/structuring when changes are added in review), but it works very well for us.
I’m fine with squash merges for one commit. But otherwise, I consider structuring changes into commits structure too.
My team merges with merge commits which hold the MR description as a commit description, and MR title as commit title.
Individual commits are retained and can describe individual changes, while the MR and merge commit describe the whole changeset.
It’s a very interactive-rebase-heavy workflow (for commit cleanups/structuring when changes are added in review), but it works very well for us.