This repository provides the best practices for creating, reviewing, and merging pull requests (PRs) across all UnifiedBits projects. Following these guidelines ensures a smooth and efficient development workflow.
When creating a PR, ensure the following:
-
Branch from
dev: Always create your branch from the latestdevbranch to avoid conflicts and ensure you're working with the latest code.git checkout dev git pull origin dev git checkout -b feature/my-feature
-
Descriptive Commit Messages: Use Conventional Commits for meaningful commit messages.
Example:
feat(auth): add login functionality fix(ui): resolve navbar overlap issue
-
Pull Request Title: The title of your PR should briefly describe the change. Follow this format:
<type>(<domain>): <short-description>Example:
feat(auth): add JWT authentication -
Link Related Issues: Reference any relevant issues in your PR description.
Example:
Closes #12 (for bug fix) or Resolves #5 (for feature implementation)
-
Provide Context: In the PR description, explain what the changes do, how they solve the problem, and any important context or steps to test.
-
Self-Review: Before submitting, review your code for clarity, performance, and adherence to project standards.
-
Request Reviewers: Assign at least two reviewers (preferably a senior developer and a team member familiar with the affected code area).
-
Be Open to Feedback: PR reviews are collaborative. Be open to constructive feedback and be prepared to make adjustments.
-
Tests: Ensure that your changes are covered by tests or add new tests if necessary. PRs without proper test coverage may be rejected.
Once your PR is approved, follow these steps:
-
Merge to
devFirst: All features and fixes should be merged into thedevbranch. Ensure your PR is targetingdev(notmain).After approval:
git checkout dev git pull origin dev git merge feature/my-feature
-
Resolve Conflicts: If there are any merge conflicts, resolve them before merging. It's good practice to rebase your branch on the latest
devto ensure smooth merging.git rebase dev
-
Squash Commits: If your PR contains multiple small commits, squash them into a single meaningful commit before merging.
-
Merge: Once everything looks good, and all tests pass, merge the PR into
dev. If you're using GitHub, you can squash and merge using the UI.
- Avoid Merging Directly into
main: PRs should never be merged directly intomain.mainshould always reflect a stable, production-ready state. - Hotfixes: Only use
hotfix/branches for urgent fixes that need to be applied directly tomain. Ensure that any fixes are also merged intodev. - Rebasing vs Merging: If your PR has diverged significantly from
dev, rebase your branch before merging to avoid creating unnecessary merge commits.
"A great PR is like a good conversation: clear, collaborative, and constructive." β UnifiedBits
Letβs maintain a smooth and efficient development process through thoughtful PRs and merges! π