Skip to content

Dev: Pull Requests

Jump to bottom
Pablo Mayrgundter edited this page Feb 8, 2024 · 8 revisions

A good pull request is:

  • Focused: One holistic change. Less is more
  • Clear: Well-factored, commented, no debugging
  • Tested: unit tests for API boundaries, mocks for services, integration tests for UX tasks
  • Summarized: A good description, with link to example of feature or fix
  • Good commit messages. "a commit message shows whether a developer is a good collaborator"

Setup

Install our precommit checks for test & lint.

yarn husky-init

Subsequent commits in your local repo will trigger yarn precommit which aliases to yarn lint && yarn test.

To bypass these for local dev, add the -n flag to git commit

git commit -nm 'Checkpoint before tests working'

Lifecycle

  1. PR Creator drives the process
  2. Use Draft PRs until ready for review. If not ready, flip back to draft. Close after 2 weeks
  3. PR Assignee is who is being asked to do the review. Other reviewers may be added as cc's. See Teams for reviewers.
  4. Always set labels and Project (Project should be Planning).
  5. Reviewer quickly evaluates the overall functionality & PR quality and request any major changes
  6. "PTAL" (please take a/another look) in review only after all prior comments addressed
  7. "PTAL" in discord, with link to PR, to get attention
  8. After approval PR creator merges if Admin
  9. Changes after approval not allowed except for small debug removal, comment improvement.

Live Demos

Creating a PR will deploy on Bldrs Netlify instance.

Please include a targeted link to demo feature in PR Description.

Merging with Upstream

Quick reference for how to merge from upstream into your fork:

# First time only: git remote add upstream https://github.com/bldrs-ai/Share
# After PR is accepted/merged in main, to sync you fork:
> git fetch upstream
> git merge upstream/main --no-commit
# then review the changes and proceed creating a commit and PR as usual
Clone this wiki locally