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

Change copy

Browse Source
This commit is contained in:
Vahid Panjganj 2017-06-16 15:59:03 +01:00
parent 3f25fbdd36
commit 09103818c6
1 changed files with 18 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
README.md
View File

@ -14,30 +14,30 @@
- [Licensing](#licensing) - [Licensing](#licensing)
## 1. Git ## 1. Git
* We use GitFlow, read more here [A successful Git branching model » nvie.com](http://nvie.com/posts/a-successful-git-branching-model/) * Use [Git Flow](http://nvie.com/posts/a-successful-git-branching-model/), read more about it [here](http://nvie.com/posts/a-successful-git-branching-model/)
* Resolve potential conflicts before making a Pull Request * Resolve potential conflicts before making a Pull Request
* Never Push into `develop` branch. * Never push into `develop` or `master` branch.
* Keep your `develop` and `master` update. * Keep your `develop` and `master` update.
* Make a Pull Requests to develop only if your build have been successful on your machine (this includes passing tests and [code style](#code style) checks ) * Make a pull requests to develop only if your build have been successful locally (including tests and [code style](#code style) checks). This is to make sure your code style is matching the Repo's.
* Merge your pull requests only after receiving approval from at least one of your team members. * Only merge your pull request after approval.
* Use [hive’s .gitignore file](./.gitignore). * Use [hive’s .gitignore file](./.gitignore).
* Make sure your `.gitignore` exclude the following from Repo * Make sure your `.gitignore` excludes the following:
* `.env` or any file containing passwords, keys, tokens or anything similar used in production * `.env` or any file containing passwords, keys, tokens or anything similar used in production
* Your editor config files (.idea, .vscode etc…) * Editor config files (.idea, .vscode etc…)
* Any generated file (compiled sources, build outputs, logs) * Generated files (compiled sources, build outputs, logs)
* You dependencies directory (node_modules, bower_components etc…) * You dependencies directory (node_modules, bower_components etc…)
* OS folder view configuration (.DS_STORE, Desktop.ini etc…) * OS folder view configuration (.DS_STORE, Desktop.ini etc…)
* Thumbnail cache files (._*, Thumbs.db etc…) * Thumbnail cache files (._*, Thumbs.db etc…)
## 2. Documentation ## 2. Documentation
* Follow hive’s `README.md` template for start (add extra sections if necessary). [hive’s README.md template](./README.sample.md) * Use [hive’s README.md template](./README.sample.md) `README.md` template (add extra sections if necessary).
* If project is broken down into more than one repo, provide links in the `README.md` file. * For project with more than one repo, provide links to all repos in each every project's `README.md`.
* Keep `README.md` updated * Keep `README.md` updated
* Comment all your code to make it as clear as possible how your app works, and what you are intending with each major section. * Comment all your code to make it as clear as possible what you are intending with each major section.
* Update your comments * Keep your comments relevent as code evolves.
## 3. Environmental Awareness ## 3. Environmental Awareness
* Depending on project size, define separate `development`, `test` and `production` environments. * Depending on project size, define separate `development`, `test` and `production` environments.
* Load your deployment specific configurations from environment variables and never add them to the codebase as constants, [look at this sample](./config.sample.js). * Load your deployment specific configurations from environment variables and never add them to the codebase as constants, [look at this sample](./config.sample.js).
* Your config should be correctly separated from the apps internals if the codebase could be made public at any moment. Use `.env` files to store your variables and add them to `gitignore` to be excluded from your code base because of course, you want the environment to provide them. Instead commit a `.env.example` which serves as a guide for developers to know which environment variables the project needs. It is important to remember that this setup should only be used for development. For production you should still set your environment variables in the standard way. * Your config should be correctly separated from the apps internals if the codebase could be made public at any moment. Use `.env` files to store your variables and add them to `gitignore` to be excluded from your code base because of course, you want the environment to provide them. Instead commit a `.env.example` which serves as a guide for developers to know which environment variables the project needs. It is important to remember that this setup should only be used for development. For production you should still set your environment variables in the standard way.
* It’s recommended to validate environment variables before your app starts , [look at this sample](./configWithTest.sample.js) using `joi` to validate provided values: * It’s recommended to validate environment variables before your app starts , [look at this sample](./configWithTest.sample.js) using `joi` to validate provided values:
@ -105,11 +105,11 @@ If less known dependency is needed, discuss it with the team before using it.
* 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` directory * Use a `./config` directory. Values to be used in config files are provided by enviromental variables.
* Put Your Long `npm` Scripts in a `./scripts` directory. This is for bash and node scripts for database synchronisation, front-end build scripts and so on. * Put Your Long `npm` Scripts in a `./scripts` directory. This is for bash and node scripts for database synchronisation, front-end build scripts and so on.
* Put your compiled or built output in a `./build` folder * Place your built output in a `./build` folder
* Use `PascalCase/camelCase` for filenames and directory names too. Which `PascalCase` is for Components. * Use `PascalCase' 'amelCase` for filenames and directory names too. Use `PascalCase` only for Components.
* `CheckBox/index.js` should have the `CheckBox` component, as could `CheckBox.js`, but **not** `CheckBox/CheckBox.js` or `checkbox/CheckBox.js` * `CheckBox/index.js` should have the `CheckBox` component, as could `CheckBox.js`, but **not** `CheckBox/CheckBox.js` or `checkbox/CheckBox.js` which are redundant.
* Ideally the directory name would match the name of the default export of `index.js` * Ideally the directory name would match the name of the default export of `index.js`
## 8. Code style ## 8. Code style
@ -119,12 +119,11 @@ If less known dependency is needed, discuss it with the team before using it.
* Use [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) for JavaScript. [Read more · GitBook](https://www.gitbook.com/book/duk/airbnb-javascript-guidelines/details) * Use [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) for JavaScript. [Read more · GitBook](https://www.gitbook.com/book/duk/airbnb-javascript-guidelines/details)
* Use [Flow type linting rules for ESLint.](https://github.com/gajus/eslint-plugin-flowtype) for [FlowType](https://flow.org/) * Use [Flow type linting rules for ESLint.](https://github.com/gajus/eslint-plugin-flowtype) for [FlowType](https://flow.org/)
* Use `.eslintignore` to exclude file or folders from linting. * Use `.eslintignore` to exclude file or folders from linting.
* Remove your `eslint` disable comments before making a Pull Request * Remove any of your `eslint` disable comments before making a Pull Request
* Always use `//todo:` comments to remind yourself and others about an unfinished job * Always use `//todo:` comments to remind yourself and others about an unfinished job
* Always comment and keep them relevant as code changes * Always comment and keep them relevant as code changes
* Remove commented block of code when possible * Remove commented block of code when possible
* Avoid console logs on client side code in production * Avoid js alerts in production
* Avoid alerts in production
* Avoid irrelevant or funny comments, logs or naming. * Avoid irrelevant or funny comments, logs or naming.
* Write testable code, avoid side effect, extract side effects, write pure functions * Write testable code, avoid side effect, extract side effects, write pure functions
* Make your names searchable with meaningful distinctions avoid shortened names. For functions Use long, descriptive names. A function name should be a verb or a verb phrase, and it needs to communicate its intention * Make your names searchable with meaningful distinctions avoid shortened names. For functions Use long, descriptive names. A function name should be a verb or a verb phrase, and it needs to communicate its intention