Actualize documentation
All checks were successful
CI / Check coding style (pull_request) Successful in 29s
CI / Check spelling (pull_request) Successful in 16s
CI / Linux (debian) (pull_request) Successful in 9m38s
CI / Linux (arch) (pull_request) Successful in 14m9s
CI / Linux (fedora) (pull_request) Successful in 10m26s
CI / Linux (ubuntu) (pull_request) Successful in 12m16s
All checks were successful
CI / Check coding style (pull_request) Successful in 29s
CI / Check spelling (pull_request) Successful in 16s
CI / Linux (debian) (pull_request) Successful in 9m38s
CI / Linux (arch) (pull_request) Successful in 14m9s
CI / Linux (fedora) (pull_request) Successful in 10m26s
CI / Linux (ubuntu) (pull_request) Successful in 12m16s
While original project, Profanity, provides valuable basis for this fork, we are not affiliated with the upstream. Therefore, documentation requires update reflecting accurate information. The docs are going to be updated further once the website is created.
This commit is contained in:
@@ -10,8 +10,8 @@ We recommend for people to always work on a dedicated git branch for each fix or
|
||||
Don't work on master.
|
||||
So that they can easily pull master and rebase their work if needed.
|
||||
|
||||
For fixing (reported) bugs we usually use `git checkout -b fix/issuenumber-somedescription`.
|
||||
When working on a new feature we usually use `git checkout -b feature/optionalissuenumber-somedescription`.
|
||||
For fixing (reported) bugs we usually use `git switch -c fix/issuenumber-somedescription`.
|
||||
When working on a new feature we usually use `git switch -c feature/optionalissuenumber-somedescription`.
|
||||
|
||||
However this is not a rule just a recommendation to keep an overview of things.
|
||||
If your change isn't a bugfix or new feature you can also just use any branch name.
|
||||
|
||||
Reference in New Issue
Block a user