sthope/gitea_templates
Template
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Merge branch 'master' of https://github.com/wearehive/project-guidelines

Browse Source
This commit is contained in:
Inam Ullah Taj 2017-07-05 14:35:59 +05:00
commit 3e232659f4
1 changed files with 79 additions and 89 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
README.md
View File

@ -25,30 +25,25 @@ We use [Feature-branch-workflow](https://www.atlassian.com/git/tutorials/compari
``` ```
git checkout -b <branchname> git checkout -b <branchname>
``` ```
* Make Changes * Make Changes
``` ```
git add git add
git commit -m "description of changes" git commit -m "description of changes"
``` ```
* Sync with remote to get changes you’ve missed * Sync with remote to get changes you’ve missed
``` ```
git checkout develop git checkout develop
git pull git pull
``` ```
* Update your feature branch with latest changes from develop by interactive rebase ([Here is why](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing)) * Update your feature branch with latest changes from develop by interactive rebase ([Here is why](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing))
``` ```
git checkout <branchname> git checkout <branchname>
git -i rebase develop git -i rebase develop
``` ```
* If you don’t have conflict skip this step. If you have conflicts, [resolve them](https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/) and continue rebase * If you don’t have conflict skip this step. If you have conflicts, [resolve them](https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/) and continue rebase
``` ```
git rebase --continue git rebase --continue
``` ```
* Push your branch * Push your branch
``` ```
git push git push
@ -120,7 +115,6 @@ Before using a package check its Github open issues, daily downloads and number
## 6. Structure and Naming <a name="structure-and-naming"></a> ## 6. Structure and Naming <a name="structure-and-naming"></a>
* Organize your files around product features / pages / components, not Roles: * Organize your files around product features / pages / components, not Roles:
``` ```
// BAD // BAD
. .
@ -144,7 +138,6 @@ Before using a package check its Github open issues, daily downloads and number
| ├── user.js | ├── user.js
| └── user.test.js | └── user.test.js
``` ```
* Place your test files next to the implementation. * Place your test files next to the implementation.
* Put your additional test files to a separate test folder to avoid confusion. * Put your additional test files to a separate test folder to avoid confusion.
* Use a `./config` folder. Values to be used in config files are provided by environmental variables. * Use a `./config` folder. Values to be used in config files are provided by environmental variables.
@ -323,15 +316,12 @@ Required: id=[integer]
Optional: photo_id=[alphanumeric] Optional: photo_id=[alphanumeric]
``` ```
* If the request type is POST, provide a working examples. URL Params rules apply here too. Separate the section into Optional and Required. * If the request type is POST, provide a working examples. URL Params rules apply here too. Separate the section into Optional and Required.
* Success Response, What should be the status code and is there any return data? This is useful when people need to know what their callbacks should expect! * Success Response, What should be the status code and is there any return data? This is useful when people need to know what their callbacks should expect!
``` ```
Code: 200 Code: 200
Content: { id : 12 } Content: { id : 12 }
``` ```
* Error Response, Most endpoints have many ways to fail. From unauthorised access, to wrongful parameters etc. All of those should be listed here. It might seem repetitive, but it helps prevent assumptions from being made. For example * Error Response, Most endpoints have many ways to fail. From unauthorised access, to wrongful parameters etc. All of those should be listed here. It might seem repetitive, but it helps prevent assumptions from being made. For example
``` ```
"Code": 403 "Code": 403
"message" : "Authentication failed", "message" : "Authentication failed",