Skip to main content

Pull requests and Releases

This page outlines the process and guidelines for submitting Pull Requests (PRs) and performing code reviews to ensure smooth collaboration and high-quality code.

Commit code according to standards​

Before submitting your code for review, please follow these guidelines for Commit message, branch naming standards, and commit lint.

Open a pull request (PR) when ready for review​

Code readiness: When your code is ready for review, open a PR. Ensure that all code is committed, and all tests are passing before requesting a review.

PR title: GitHub typically suggests a PR title based on your commit messages, which we usually accept. However, if your PR includes multiple commits, GitHub's suggested title may not match precisely, and you'll need to adjust it manually. In these cases, ensure the PR title still follows the commit message format described in the link above.

Assign reviewers: Make sure to assign the appropriate reviewers for your PR.

Review feedback process​

After receiving comments or feedback from the reviewer(s), make necessary code changes and improvements.

Update code: Push the new commits to the same branch. There’s no need to open a new PR unless there’s a fundamental change in approach.

PR updates: Reviewers can see the changes made after the feedback and will re-evaluate the PR.

Multiple commits in a PR​

It’s acceptable to have multiple commits in a single PR. Each commit should represent a meaningful change or fix.

Best practice: Try to keep your commits logically grouped and ensure they have clear commit messages. This makes the review process easier.

Commit example

feat(TRPS-1234): multiselect dropdown
chore(TRPS-1235): adjust tailwind styling
chore(TRPS-1236): adjust bitbucket pipeline step

Squash and merge when merging PRs into develop​

Squash and Merge: Always use the "Squash and Merge" strategy when merging a PR. This merges all commits into one, creating a clean history without multiple minor commits cluttering the project. This only relates when you are finished with your work and want to merge your branch into develop. When you open a PR for releases we are using git merge strategy.

Commit history: The squash commit message should be meaningful and concise, summarizing the overall change.

Rebase your branch​

Rebase on develop: Before opening a PR, ensure that your branch is up to date with the latest changes in the develop branch. Rebase your branch on develop to avoid conflicts and ensure compatibility.

Resolve conflicts: If there are any merge conflicts while rebasing, resolve them before opening the PR. This reduces the time spent addressing conflicts later in the review process.

Rebase before merging: Rebase your branch one final time before merging to ensure you’re merging the latest code and avoid introducing conflicts.

📘 Merge Strategy When Doing a Release PR (Git-Flow)​

In the Git-Flow model, branches are organized as follows:

  • main – Stable, production-ready code.
  • develop – Integration branch for development.
  • release/* – Release preparation branch.
  • feature/* – Feature development.
  • hotfix/* – Urgent fixes to production.

🚀 When to Create a Release PR​

  • When develop has reached a stable and tested state.
  • Create a new branch: release/x.y.z from develop.
  • Finalize the release (QA, bug fixes, documentation).
  • Create a PR from release/x.y.z → main.

🔀 Merge Strategy​

1. Merge Method​

✅ Use: Merge Commit

  • Preserves detailed commit history.
  • Aids traceability and debugging.
  • Avoid Squash & Merge unless commits are too noisy or trivial.

2. Target Branch​

🧭 Always merge into: main

Release PRs must target the main branch for production deployment.

3. Post-Merge Actions​

After merging the release PR into main:

# Tag the release
git tag -a vX.Y.Z -m "Release vX.Y.Z"
git push origin vX.Y.Z

# Merge release back into develop
git checkout develop
git merge release/x.y.z
git push origin develop