Best Practices #1
Description
For the duration of this project, you're expected to work with a GitHub flow workflow, and follow the guidelines outlined in the DSCI 524 lecture material. In addition, you are also expected to adhere to (i.e. will be graded on) the following in 532:
- Always work on feature branches, not directly on main.
- Commit to your branch often; each commit should be atomic (include only one meaningful unit of changes).
git add --patchis your friend.
- Write descriptive, brief commit messages that explain the purpose of the commit.
- Commit messages should be capitalized and complete the sentence "This commit will..."
- Good examples: "Make the readme more welcoming", "Refactor optional import logic", "Enable PPI setting on PNG CLI export"
- Bad examples: "added notebook", "Update analysis", "Fixes", "I hope this works", "asdfsdfasdf" (we've all been there)
- Break out the feedback from the TAs from Gradescope into individual issues so that you can track them in your project and address each piece of feedback separately.
- Assign team members to issues and close them via PRs using keywords.
- All code that is added to the repo should come via PRs, no code should be pushed straight to main.
- Each PR should contain one main feature/fix (possibly consiting of a few tightly connected smaller features/fixes).
- Each PR should have one approving review before being merged.
- Only use "squash and merge", so that you can keep an easy to read commit history on main while also being able to track details for each commit via the PR link in the commit message.
- To make this the default, you can go to Settings and uncheck Allow merge commits under Pull Requests.