Added documentation for branches (#194)

# Pull Request

## 📖 Description

<!--- Provide some background and a description of your work. -->
This change adds documentation for the naming and creation of branches.

## ✅ Checklist

### General

<!--- Review the list and put an x in the boxes that apply. -->

- [ ] I have added tests for my changes.
- [ ] I have tested my changes.
- [x] I have updated the project documentation to reflect my changes.

BRANCH_GUIDE.md

@@ -0,0 +1,19 @@
+# Branch guide
+
+This is the branch guide for the FAST Tooling repository. When contributing to this project please follow the standards defined in this guide.
+
+## Default
+
+The `main` branch is the default branch. It is used for all releases pinned to the current major version. Most pull requests should be merged directly into this branch so that it can be automatically checked for publishing.
+
+## Features
+
+If a large feature or a breaking change has been defined, a feature branch may be created. To be significant enough work to require a feature branch, the work must comprise of more than one pull request. See the [style guide](./STYLE_GUIDE.md) for naming conventions, which must be followed to trigger GitHub workflows that are used as the build gate.
+
+### Changelog
+
+Due to the default behavior of beachball (the package publishing utility used in this repository) the script in `package.json` using `beachball check` which defaults to checking for changes against the default branch must be updated. The branch creation should start by targeting the check for changes against the feature branch specifically, to do this refer to the branch settings in [beachball options](https://github.com/microsoft/beachball/blob/master/docs/overview/configuration.md#options). This change must be reverted before inclusion to the default branch.
+
+### Merging
+
+When merging a feature branch to the default branch, changes should not be squashed to preserve history. This will require a special action from someone with the necessary security privileges.

CONTRIBUTING.md

@@ -62,7 +62,7 @@ Packages are located within the `packages` folder of the repository. Each packag
 Prior to submitting a pull request please follow the following steps.
 
 1. Review and adhere to the standards defined in the [style guide](./STYLE_GUIDE.md).
-2. Rebase your branch from `main` or use the *merge* button provided by GitHub. If you're new to rebasing checkout [Merging vs Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).
+2. Rebase your branch from your target branch (typically `main`) or use the *merge* button provided by GitHub. If you're new to rebasing checkout [Merging vs Rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).
 3. Generate a change file(s) using `npm run change` located in `./change/*` and used for continuous delivery. As a convenience, the interactive prompt looks to provide recent commit messages for use in the description. *For changes which do not affect the published package(s), please use "none" when selecting the change type*.
 4. Finally, when submitting your pull request please make the title clear and concise, provide a description of the change, and specify any issues that will be closed.
 
@@ -70,7 +70,13 @@ Prior to submitting a pull request please follow the following steps.
 If you are addressing multiple issues which are unrelated, consider either doing multiple pull requests, or generate separate change files to ensure accurate generation of changelogs and versioning of packages.
 :::
 
-For additional details on package versioning and changelog generation read the [Publishing](./PUBLISHING.md) documentation.
+For additional details on package versioning and changelog generation read the [publishing](./PUBLISHING.md) documentation.
+
+:::note
+If you are finding that your changes are either breaking changes or require multiple pull requests, open an issue to discuss this.
+:::
+
+For additional details on branch management read the [branch guide](./BRANCH_GUIDE.md) documentation.
 
 ### Merging a pull request
 

STYLE_GUIDE.md

@@ -2,6 +2,14 @@
 
 This is the code style guide for the FAST tooling repository. When contributing to this project please follow the standards defined in this guide.
 
+## Branches
+
+Branches that will be used to create a pull request to the default branch or a feature branch should use the naming pattern `users/{username}/{purpose-of-change}`.
+
+### Features
+
+Branches encompassing a larger body of work that will be contributed by multiple users or include multiple pull requests should use the naming pattern `features/*`.
+
 ## Files
 
 File and folder naming in general should not include special characters or spaces. Alphanumeric is preffered, separated by dash or underscore depending on the type of file. Names should be as concise as possible while also being meaningful, and should attempt to follow any standard set by a standards governing body such as W3C.