Best practices?

[MikeMcC399]

Are there any "best practice" documents available for ensuring that teams working in a repository which uses cycjimmy/semantic-release-action produce consistent results?

Typically after a branch for a fix or feature is created with its initial commit, it will get worked on and improved causing additional commits to be made to the branch.

At the same time it is often the case that the default branch (main, master, develop, etc.) will be advancing with commits from other sources, so if the fix/feature branch is kept up to date it might also contain merge commits in it.

At some stage a PR will be opened and then merged, which is when cycjimmy/semantic-release-action comes into play.

1. Where is the best place to the commit message such as feat: great new addition which cycjimmy/semantic-release-action acts on?
   • in an individual commit as part of the fix/feature branch?
   • in the title of a PR?
   • in the merge commit when the PR is merged?
2. During the development of the fix/feature branch, what is the best way to keep the branch aligned with the default branch?
   • use the Update button on GitHub (which does a merge commit into the fix/feature branch)?
   • rebase the fix/feature branch locally and force push to GitHub?
3. Which type of PR merge is best?
   • Create a merge commit?
   • Squash and merge?
   • Rebase and merge?
4. Whose responsibility is it to ensure that the right commit message is created and used?
   • the PR submitter?
   • the person who merges the PR?

Thanks for any pointers where these questions may already have been answered and solved!

[MikeMcC399]

https://github.com/amannn/action-semantic-pull-request/blob/main/README.md writes

"If your goal is to create squashed commits that will be used for automated releases, you'll want to configure your GitHub repository to use the squash & merge strategy and tick the option "Default to PR title for squash merge commits"."