title: Limiting conventional commits only to pull requests
body: <p>As part of my CI/CD pipeline workflow, I am considering to make use of <a href="https://www.conventionalcommits.org/en/v1.0.0/" rel="nofollow noreferrer">conventional commits</a> to auto-generate release drafts in github. The idea of creating draft is to allow the code owners to review release notes before publishing it.</p>
  <p>However, I am worried if this could cause following two issues:</p>
  <ol>
  <li>If we go ahead and create each commit message as conventional commit we would end
  up with a huge log of changes as disconnected information in release drafts which would need to be manually refactored to make any sense out of it before being published</li>
  <li>Alternative approach, I could think of is to refrain committing changes until all related changes are completed and when done push all related changes under a single commit message. However, this goes against the proposition of CI/CD as it would delay early merges</li>
  </ol>
  <p>As a solution to the aforementioned issues, I was thinking of making use of conventional commits only when I create pull-requests to the mainline by the end of completion of a feature. This way I could avoid all the noise in the release draft and yet automate creation of release notes. But I am not very sure if this is the right approach. I would like to know what strategy others are employing to deal with this issue and if the approach I am planning to take is right? Or if we are better off creating release notes manually? Thanks!</p>