Functionality (does it work?), security (no hardcoded secrets, proper auth), performance (no N+1 queries, proper indexes), style (follows conventions), tests (new code is tested), and documentation (complex logic is commented, API docs updated).
What should code reviewers check in a PR?
More FAQs in GitHub Repository Best Practices for Node.js Projects Branching, PRs, and Code Review
Use main (production), develop (integration), feature/* (new features), bugfix/* (fixes), and hotfix/* (urgent production fixes). Create feature branches from develop, merge back to develop, and merge develop to main for releases.
Commits start with a type: feat (new feature), fix (bug fix), docs (documentation), refactor (code restructuring), test (tests), chore (maintenance). Followed by a concise description in present tense. Example: 'feat: add connection request API'.
node_modules/, .env files, logs (*.log, logs/), build artifacts (dist/, build/), IDE files (.vscode/, .idea/), OS files (.DS_Store), and coverage reports (coverage/). Never commit secrets or dependencies.
Still have questions?
Browse all our FAQs or reach out to our support team
Want to upskill yourself?
Your learning library
Small steps. Big possibilities.
Find your next course. Build something great.