Update BestPractices.md with Git flow instructions

This commit updates the BestPractices.md file to provide clear instructions on using Git flow in our development process. It includes guidelines for creating feature branches, merging features into the develop branch, and maintaining a clean repository. Additionally, it explains how to use the preview branch for pre-production review and synchronization with the main branch. This workflow enables efficient change management and reduces the risk of errors in production.

No breaking changes introduced.

Related: #123

docs/BestPractices.md

@@ -0,0 +1,54 @@
+Focus on development workflows, coding standards, and Git flow practices. Include sections for each aspect of Git flow, coding standards, and other technical best practices our /team should follow.
+
+### 1. **Feature Branches**
+
+- **Start New Features:** When beginning work on a new feature, create a feature branch off the `develop` (or `preview`, if you've chosen to rename it, which we did) branch. Use the convention `feature/your-feature-name`.
+- **Finish Features:** Once a feature is completed and tested, merge it back into the `develop` branch. Delete the feature branch if it's no longer needed.
+
+### 2. **Develop and Preview Branch**
+
+- **Continuous Integration:** Regularly push changes from feature branches into this branch to integrate and test new developments. If you're using `preview` as your integration branch, this serves as a live staging area for your team to review.
+
+### 3. **Release Branches**
+
+- **Prepare Releases:** When you're ready to prepare a new release, create a release branch off `develop`. Use the naming convention `release/x.y.z` based on your versioning.
+- **Finalize and Merge:** After final testing and adjustments, merge the release branch into `main` (or `master`) and back into `develop` to capture any last-minute changes made during the release process. Tag the merge into `main` with the version number.
+
+### 4. **Hotfix Branches**
+
+- **Urgent Fixes:** For urgent fixes to your production code, create a hotfix branch directly off `main`. Name it using the convention `hotfix/urgent-fix-name`.
+- **Merge Back:** Once the fix is complete, merge the hotfix branch into both `main` and `develop` (or `preview`), ensuring that the fix is incorporated into future releases.
+
+### 5. **Main Branch**
+
+- **Production Ready:** The `main` branch represents the production-ready state of your project. Only merge into `main` from release or hotfix branches.
+
+### 6. **Version Tagging**
+
+- **Tag Releases:** When you merge a release into `main`, tag the commit with the version number to mark the release point. If you've set up a `version/` prefix for tags, include it in your tag name.
+
+### Best Practices
+
+- **Regular Pulls:** Regularly pull changes from the remote to keep your local branches up to date and minimize merge conflicts.
+- **Branch Cleanup:** Delete branches after merging them to keep your repository clean and manageable.
+- **Communication:** Ensure all team members are familiar with the Git flow process and the roles of different branches. Clear communication is key to avoiding confusion.
+
+If you've fast-forwarded the `preview` branch to the last commit of the `main` branch and then checked out to the `preview` branch, you've effectively synchronized the `preview` branch with the current state of `main`. This setup positions the `preview` branch to receive all future updates and changes intended for pre-production or staging review before they are merged into `main`, aligning with the workflow you seem to be establishing.
+
+### Moving Forward with Updates on the `preview` Branch:
+
+1. **Committing to `preview`:** With the `preview` branch checked out, any new commits you make will now be part of the `preview` branch. This is ideal for introducing and testing new features, bug fixes, or other changes without affecting the production-ready `main` branch.
+
+2. **Review and Testing:** Use the `preview` branch as a staging area to review changes, conduct tests, and ensure everything works as expected in an environment that mirrors production as closely as possible.
+
+3. **Pull Requests for Merging:** When you're satisfied with the changes in the `preview` branch, create a pull request (PR) to merge these changes into `main`. This PR process facilitates code review and discussion among team members, ensuring that only thoroughly vetted changes make their way to production.
+
+4. **Continuous Deployment with Vercel:** If your project is integrated with Vercel, remember that Vercel automatically creates preview deployments for every push to branches other than `main`. This means that pushing changes to the `preview` branch will generate a preview deployment that you can share with your team or stakeholders for feedback.
+
+5. **Keeping `preview` Updated:** Periodically, you may want to sync the `preview` branch with the `main` branch to ensure it reflects the latest production state. This can be done through a fast-forward merge from `main` to `preview`, similar to what you've already done, or through a regular merge if the branches have diverged significantly.
+
+6. **Communication:** Ensure that all team members are aware of the workflow and understand that the `preview` branch is where updates should be pushed for pre-production review.
+
+This workflow allows your team to efficiently manage and review changes in a controlled environment, reducing the risk of introducing errors into the production codebase.
+
+By adhering to these practices, you can leverage Git flow to streamline your development process, improve collaboration, and manage releases more effectively.