Skip to content

Git Flow

Nick Sweeting edited this page Oct 23, 2023 · 3 revisions

Git Flow

Normal Work: dev -checkout> feature-branch -PR> dev -PR> master -deploy> prod
Beta Testing: dev -checkout> feature-branch -deploy> beta
Emergency Hotfix: prod -checkout> hotfix-branch -deploy> prod -PR> master

Pull Request Checklist

Please make sure to do all of the following with any Pull Request:

  • get review & approval from both @nick and @max
  • get a CircleCI checkmark (passes all tests & linter)
  • do the eyeball test: run ./manage.py runserver and play a hand to make sure nothing is visibly broken
  • check the CircleCI screenshots to make sure pages are rendering correctly
  • make sure no unnecessary staticfiles or dumps are in your PR

There will be exceptions to these rules, but make sure they are exceptions for a concrete reason!

Checklist when adding/removing/renaming urls

  • make sure ui/urls.py is correct
  • grep for uses of the url via name (reverse(name) and {% url name %})
  • grep for uses of the hardcoded url (in js files and elsewhere)
  • make sure sitemap.xml is correct (in urls.py)
  • make sure page is screenshoted in circle.yml
  • make sure post_ci_hook.sh links to the screenshot artifact from circle.yml

Pull Request Tips

  • interactive rebase git rebase -i to squash micro commits like "fixed css", "actually fixed css", "ugh 3rd trys a charm" together before pushing local branches to remote
  • don't squash other commits, leave them as individual commits whenever you merge PRs (to preserve granular line-by-line git blame)
  • merge dev (or whatever base branch you're working off) into your local branch periodically, this helps prevent merge conflicts from snowballing into massive problems later on
  • don't bother fixing merge conflicts in procedurally generated files (e.g. package-lock.json, requirements.lock, test_data/example.bin, etc.), just regenerate them with their respective tools and commit the regenerated output
image