From 3a8ac64b841a4a9dab9cc400b075e6c6eaeb4918 Mon Sep 17 00:00:00 2001 From: Clark Van Oyen Date: Wed, 29 May 2024 09:30:50 -0700 Subject: [PATCH] Update GIT.md --- developers/GIT.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/developers/GIT.md b/developers/GIT.md index 62f384d6c6..35b979b7a5 100644 --- a/developers/GIT.md +++ b/developers/GIT.md @@ -112,6 +112,8 @@ develop in this case. When you create your pull request: + - Remember to run Linting if applicable. + - It’s best to check the tests pass before merging (but you’ll be notified if they fail in Slack anyway). Don’t break the tests in `develop` for long… If you do, fix them ASAP because other devs will be unable to test their work otherwise.- - Review it on BitBucket yourself because it lets you find embarassing mistakes without your team seeing them ;) - Comment on specific lines you want the reviewer to notice. @@ -121,9 +123,7 @@ When you create your pull request: the code at any time based on the team's needs. Communicate about what you're doing. If code is merged before you review, the reviewer can still add comments and changes can be patched in as needed. - - Do not merge unless the tests are passing. Don't break the tests in - `develop`. If you do, fix them ASAP because other devs will be - unable to test their work otherwise. + ## Tips for Code Reviews