Version Control Strategy ​

Maintaining the trivial-api and trivial-ui repositories calls for diligent attention to version control practices. This guide provides an overview of the recommended steps for contributing effectively to these repositories.

1. Update main to the latest stable version ​

git pull origin main

2. Checkout a new branch with a clear name ​

Branch name schema:

[ general code purpose ]/[ specific feature target ]

Ex.

git checkout -b fix/invite-email-not-sending

3. Make your additions and edits ​

Make a change, verify the change, then add and commit that change:

git add [ file ]
git commit -m 'specific verified change'

Commit Strategy

• Follow a squashing commit strategy that groups commits by larger ideas as changes are verified. Find a balance of readable commits that group more specific changes into larger ideas

• Avoid mixing whitespace/style and functional changes into a single commit branch. Group all white space changes into a specific commit when they are necessitated

git rebase -i HEAD~N (N = total commits to squash)

4. Push your changes to the origin repository as needed ​

Pushing can be done as necessary to allow for code portability and collaboration

Ex.

git push origin feature/contract-function-grouping

However, pushing squashed commits that have previously been pushed will require force-pushing. Please attempt to minimize this by squashing before pushing commits

git push -f origin update/improved-email-templates

5. Open a PR titled with the branch name. ​

• Always provide at least a minimal description of the changes and additions implemented

• Add initial labels for easier parsing

• Leave all PRs as Draft PRs until they are fully finished

• Tag the reviewer and mark PRs when ready for review

6. Review the PR ​

• All PRs must be reviewed by a non-author reviewer

• Reviews should primarily cover function, edge case precautions, and general code safety

7. Implement recommended changes ​

Continue to group, reorder, and squash commits from recommended changes

8. Make a Final Lint of the reviewed PR ​

• Linting should not introduce any functional changes

• Use the recommended linter where applicable

• Ensure that all commits have been properly grouped and squashed

• Aim for a minimal (ideally 1) number of commits which each summarize a functional group of changes

9. Make a Final Review of the PR ​

• This review should be a skim that checks no functional changes were introduced during linting

• Ensure that the PR has a summary description of changes

10. Approve and Merge the PR ​

Once approved, the author is responsible for merging the PR and coordinating mirroring.

11. Mirror to any applicable private repos as needed ​

See dedicated page for mirroring repositories

Troubleshooting ​

If you find yourself in a rebase and aborting isn’t sufficient, you can use reflog like an undo.