7d0aeeefe5
* Improve format and clarity of the docs [ci skip] While this change produces a lot of git noise by enacting what seems like an arbitrary linewrap on most of the files in the documentation it will result in better version control and tracking of the changes in the documentation. For example, as it currently stands, if one was to make a PR to move a comma in a sentence because each paragraph in most of the files is on a single line, that small change would look in the git history like the author had modified the entire paragraph. In reality, this author just moved a comma. This change also includes a significant number of modifications to the more article-esque docs. Many of these docs were written in a sort of stream-of-conciousness and aren't as easy to read as they could be. Hopefully this is the first of several readability changes. If we could get these docs to a more accessible reading level, we would probably see an increase in contributions. :) * Delegate markdown wrapping to Prettier * Add linewrapping explanation in the docs [ci skip]
617 B
617 B
| title |
|---|
| Creating a Feature Branch |
Creating a feature/bug branch
When you are working on a bug, feature, or improvement, you will need to create a branch.
Generally, it can be helpful to prefix a branch name with feature or bug to
denote what kind of code a reviewer can expect to find on the branch.
For features or improvement, you should create a branch as follows:
git checkout -b feature/that-new-feature
For a bug branch, you should do as follows:
git checkout -b bug/fixing-that-bug
When working on the docs, you can do this:
git checkout -b docs/adding-those-docs