Merge Requests
- Naming: Merge request names should follow the pattern
<category/JIRA-TICKET: Short description>. Categories are the same as for branches. Example:chore/CORP-52: Update renovate settings. - Squash Commits: Commits should be squashed before merging. In GitLab, check the Squash commits box in the “Ready to merge!” section. In GitHub, change the “Merge” option in the dropdown menu to “Squash and merge”.
- Review Process: Every merge request (except bug fixes) should have at least one approval before it can be merged.
- Feedback and Implementation:
- Developers should not automatically rework everything based on feedback.
- Provide a rationale for your implementation choices and engage in constructive discussion.
- If you agree with feedback, acknowledge it and indicate your intention to make the necessary updates.
- Whenever you work on proposed changes, resolve the thread. This is the responsibility of the author of the merge request, not the reviewer.
Standardized Comment Format
Section titled “Standardized Comment Format”- Comments should follow conventional comments.
- Comment should have prefix:
<label>: .... Labels includeissue,suggestion,nitpick,question,thought, andpraise. - Decorations give additional context for a comment, e.g.
suggestion(non-blocking): <description>(it might not be clear if suggestion is blocking).