Workflow

A seemingly good workflow when doing Front End development

Overview

• Creating a new feature branch

• Commits

• PRs

---

When creating a new feature branch, generally:

1. Create new feature branch locally (off of develop)

   • git checkout develop (checkout your local develop branch)

   • git pull (pull in any changes from remote develop branch)

     • git pull origin develop (if develop isn't connected to remote develop branch)

     • git branch --set-upstream-to=origin/develop (to connect local develop branch to remote develop branch... then you can run git pull going forward)

   • git checkout -b new-branch-name (create new local branch)

2. Push new feature branch onto GitHub (pavewisepro/pavewise-web)

   • git push -u origin new-branch-name (creates new/connected remote branch)

3. Create a "PR Draft" with your GitHub branch

   • (this will allow the automated build checks to happen, creating a history of the ability of your commits to build -- this is useful in case something breaks and we have to go back to a time where things were working)

     • (eventually, we may create GitHub Actions that run these checks on commits to any GitHub branches, but do this until that happens)

   • Choose yourself as an 'assignee' on the PR

---

When doing a commit, generally:

1. Run yarn lint:format prior to commit

   • (if not formatted correctly, the automated build checks on GitHub will fail)

2. Push commit to GitHub

   • git push (pushes any local changes to connected remote branch)

---

When making a PR, generally:

1. Rebase onto develop prior to converting from "PR Draft" to "PR"

   • git rebase origin/develop (attempt rebase onto remote develop)

     • If merge conflicts arise:

       • (1) VSCode > Source Control or GitHub extension

       • (2) GitHub Desktop (app)

       • (3) Git

         • Resolve a conflict, then

         • git add . (mark the conflict as resolved)

         • git rebase --continue (continue the rebase process)

   • git push -f (must force push after rebasing)

   • (there may have been merges into develop branch since you branched off of it... once your PR is approved, having rebased your feature branch will allow a clean merge into develop without merge conflicts after PR approval (and will allow reviewer to see final/rebased changes when reviewing))

2. PR (convert from "PR Draft" to "PR")

   • (click "Request review for changes")

   • Choose the appropriate people for "Request review"

---

Splitting apart a PR into PR chunks (or just wanting to bring in

git checkout weather-impacts-chart-fe -- 'src/pages/_mui/projects/[projectId]/_components/SectionWeatherImpacts’