Putting the message in git puts the information closer to the code, since the pr isn’t in git itself but instead the git forge. You can for example search the text of git messages from the git cli, or come across the explanation when doing git blame. I sometimes write verbose commit messages and then use them as the basis for the text in the pr, that way the reviewer can see it easily, but it’s also available to anyone who might come across it when doing git archeology
It obviously depends on your exact git workflow, but my last team had things setup so that the code content of a MR was automatically squashed on merge, and the text if the MR itself was automatically set as the content of the new singular git commit.
This was largely the best of both worlds because your commits could have almost any text, and the description of what changed could be updated as needed when making the MR. But it ultimately ended up in the git history where it belonged.
Of course, I still had some trouble trying to get the team to describe their changes well in the MR at times - but that’s a different problem entirely.
Always squashing is a bit much for my taste, sometimes the individual commits have interesting information! Text from the MR in the merge commit is great though, maybe I should see if we can set that up with gitlab and propose that we start doing that at work.
Normally when I merge a PR I put the long PR message (if there is one) in the merge commit (again if there is one), rather than shitty Merge PR from patch1 that people seem to use.
If I’m not keeping the branch (usually PRs are not big enough to make preserving multiple commits useful) then I squash & merge which gives you the chance to edit the commit message and copy details from the PR message in.
I hate the default merge commits. I got quite frustrated when a FOSS project rejected (or didn’t come to a conclusion) my proposal for merge commits to also follow the commit formatting guidelines.
The cherry on top is merge commits describing which branch is being merged. But the branch disappears with that merge. I consider it worthless. The branch name is a name of the drafting process. There is no value to it when it lands.
I just keep my commit messages one-liners and elaborate more on pull requests, where there’s enough context to really justify the change.
Putting the message in git puts the information closer to the code, since the pr isn’t in git itself but instead the git forge. You can for example search the text of git messages from the git cli, or come across the explanation when doing
git blame. I sometimes write verbose commit messages and then use them as the basis for the text in the pr, that way the reviewer can see it easily, but it’s also available to anyone who might come across it when doing git archeologyIt obviously depends on your exact git workflow, but my last team had things setup so that the code content of a MR was automatically squashed on merge, and the text if the MR itself was automatically set as the content of the new singular git commit.
This was largely the best of both worlds because your commits could have almost any text, and the description of what changed could be updated as needed when making the MR. But it ultimately ended up in the git history where it belonged.
Of course, I still had some trouble trying to get the team to describe their changes well in the MR at times - but that’s a different problem entirely.
Always squashing is a bit much for my taste, sometimes the individual commits have interesting information! Text from the MR in the merge commit is great though, maybe I should see if we can set that up with gitlab and propose that we start doing that at work.
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.
Normally when I merge a PR I put the long PR message (if there is one) in the merge commit (again if there is one), rather than shitty
Merge PR from patch1that people seem to use.You can actually change the behaviour on GitHub to be sane: https://blog.mergify.com/how-to-change-the-default-commit-message-on-github/amp/
If I’m not keeping the branch (usually PRs are not big enough to make preserving multiple commits useful) then I squash & merge which gives you the chance to edit the commit message and copy details from the PR message in.
I hate the default merge commits. I got quite frustrated when a FOSS project rejected (or didn’t come to a conclusion) my proposal for merge commits to also follow the commit formatting guidelines.
The cherry on top is merge commits describing which branch is being merged. But the branch disappears with that merge. I consider it worthless. The branch name is a name of the drafting process. There is no value to it when it lands.
One of the reasons I hate merge commits and just force linear history on the repos I control.