Fix typo and add space between Chinese and English (#110)
This commit is contained in:
赵吉彤
Vahid Panjganj
parent
dc521baa00
commit
4baf60bab3
35
README-zh.md
35
README-zh.md
@ -43,29 +43,29 @@ JavaScript工程项目的一系列最佳实践策略
|
||||
* 在功能分支中执行开发工作。
|
||||
|
||||
_为什么：_
|
||||
> 因为这样，所有的工作都是在专用的分支而不是在主分支上隔离完成的。它允许您提交多个pull合并请求而不会导致混乱。您可以持续迭代提交，而不会使得那些很可能还不稳定而且还未完成的代码污染主分支。[更多请阅读...](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow)
|
||||
> 因为这样，所有的工作都是在专用的分支而不是在主分支上隔离完成的。它允许您提交多个 pull request 而不会导致混乱。您可以持续迭代提交，而不会使得那些很可能还不稳定而且还未完成的代码污染 master 分支。[更多请阅读...](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow)
|
||||
|
||||
* 从 `develop` 独立出分支。
|
||||
|
||||
_为什么：_
|
||||
> 这样，您可以保持 `master` 中的代码稳定性，这样就不会导致构建问题，并且几乎可以直接用于发布（当然，这可能对某些项目来说要求会比较高）。
|
||||
> 这样，您可以保持 `master` 分支中的代码稳定性，这样就不会导致构建问题，并且几乎可以直接用于发布（当然，这可能对某些项目来说要求会比较高）。
|
||||
|
||||
* 永远也不要将分支（直接）推送到 `develop` 或者 `master` ，请使用合并请求（Pull Request）。
|
||||
|
||||
_为什么：_
|
||||
> 通过这种方式，它可以通知整个团队他们已经完成了某个功能的开发。这样开发伙伴就可以更容易对代码进行评审，同时还可以互相讨论所提交的需求功能。
|
||||
> 通过这种方式，它可以通知整个团队他们已经完成了某个功能的开发。这样开发伙伴就可以更容易对代码进行 code review，同时还可以互相讨论所提交的需求功能。
|
||||
|
||||
* 在推送所开发的功能并且发起合并请求前，请更新您本地的`develop`分支并且完成交互式变基操作（interactive rebase）。
|
||||
|
||||
_为什么：_
|
||||
> 变基操作会将（本地开发分支）合并到被请求合并的分支（ `master` 或 `develop` ）中，并将您本地进行的提交应用于所有历史提交的最顶端，而不会去创建额外的合并提交（假设没有冲突的话），从而可以保持一个漂亮而干净的历史提交记录。 [更多请阅读 ...](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)
|
||||
> rebase 操作会将（本地开发分支）合并到被请求合并的分支（ `master` 或 `develop` ）中，并将您本地进行的提交应用于所有历史提交的最顶端，而不会去创建额外的合并提交（假设没有冲突的话），从而可以保持一个漂亮而干净的历史提交记录。 [更多请阅读 ...](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)
|
||||
|
||||
* 请确保在变基并发起合并请求之前解决完潜在的冲突。
|
||||
|
||||
* 合并分支后删除本地和远程功能分支。
|
||||
|
||||
_为什么：_
|
||||
> 如果不删除需求分支，大量僵尸分支的存在会导致分支列表的混乱。而且该操作还能确保有且仅有一次合并到`master` 或 `develop`。当且仅当这个功能分支还处于开发中时才应该存在。
|
||||
> 如果不删除需求分支，大量僵尸分支的存在会导致分支列表的混乱。而且该操作还能确保有且仅有一次合并到`master` 或 `develop`。只有当这个功能还在开发中时对应的功能分支才存在。
|
||||
|
||||
* 在进行合并请求之前，请确保您的功能分支可以成功构建，并已经通过了所有的测试（包括代码规则检查）。
|
||||
|
||||
@ -99,7 +99,7 @@ JavaScript工程项目的一系列最佳实践策略
|
||||
git checkout -b <分支名称>
|
||||
```
|
||||
|
||||
* 新增一下代码变更。
|
||||
* 新增代码变更。
|
||||
|
||||
```sh
|
||||
git add
|
||||
@ -139,10 +139,10 @@ JavaScript工程项目的一系列最佳实践策略
|
||||
```
|
||||
|
||||
_为什么:_
|
||||
> 当您进行变基操作时，您会改变功能分支的提交历史。这会导致Git拒绝正常的 `git push` 。那么，您只能使用 `-f` 或 `--force` 参数了。[更多请阅读...](https://developer.atlassian.com/blog/2015/04/force-with-lease/)
|
||||
> 当您进行 rebase 操作时，您会改变功能分支的提交历史。这会导致 Git 拒绝正常的 `git push` 。那么，您只能使用 `-f` 或 `--force` 参数了。[更多请阅读...](https://developer.atlassian.com/blog/2015/04/force-with-lease/)
|
||||
|
||||
* 提交一个合并请求（Pull Request）。
|
||||
* 合并请求会被负责代码审查的同事接受，合并和关闭。
|
||||
* Pull Request 会被负责代码审查的同事接受，合并和关闭。
|
||||
* 如果您完成了开发，请记得删除您的本地分支。
|
||||
|
||||
```sh
|
||||
@ -154,7 +154,7 @@ JavaScript工程项目的一系列最佳实践策略
|
||||
```
|
||||
|
||||
<a name="writing-good-commit-messages"></a>
|
||||
### 1.3 如何写好提交说明
|
||||
### 1.3 如何写好 Commit Message
|
||||
|
||||
坚持遵循关于提交的标准指南，会让在与他人合作使用 Git 时更容易。这里有一些经验法则 ([来源](https://chris.beams.io/posts/git-commit/#seven-rules)):
|
||||
|
||||
@ -204,9 +204,9 @@ JavaScript工程项目的一系列最佳实践策略
|
||||
|
||||
_为什么：_
|
||||
> 您会有令牌，密码和其他有价值的信息。这些配置应正确地从应用程序内部分离开来，这样代码库就可以随时独立发布，不会包含这些敏感配置信息。
|
||||
_怎么做：_
|
||||
> _怎么做：_
|
||||
> 使用 `.env` 文件来存储环境变量，并将其添加到 `.gitignore` 中使得排除而不被提交（到仓库）。另外，再提交一个 `.env.example` 作为开发人员的参考配置。对于生产环境，您应该依旧以标准化的方式设置环境变量。
|
||||
[更多请阅读](https://medium.com/@rafaelvidaurre/managing-environment-variables-in-node-js-2cb45a55195f)
|
||||
> [更多请阅读](https://medium.com/@rafaelvidaurre/managing-environment-variables-in-node-js-2cb45a55195f)
|
||||
|
||||
* 建议您在应用程序启动之前校验一下环境变量。 [看这个例子](./configWithTest.sample.js) ，它使用了 `joi` 去校验提供的值。
|
||||
|
||||
@ -341,7 +341,7 @@ JavaScript工程项目的一系列最佳实践策略
|
||||
|
||||
**不规范**
|
||||
|
||||
```
|
||||
```
|
||||
.
|
||||
├── controllers
|
||||
| ├── product.js
|
||||
@ -349,11 +349,11 @@ JavaScript工程项目的一系列最佳实践策略
|
||||
├── models
|
||||
| ├── product.js
|
||||
| └── user.js
|
||||
```
|
||||
```
|
||||
|
||||
**规范**
|
||||
|
||||
```
|
||||
```
|
||||
.
|
||||
├── product
|
||||
| ├── index.js
|
||||
@ -363,7 +363,7 @@ JavaScript工程项目的一系列最佳实践策略
|
||||
| ├── index.js
|
||||
| ├── user.js
|
||||
| └── user.test.js
|
||||
```
|
||||
```
|
||||
|
||||
_为什么：_
|
||||
> 比起一个冗长的列表文件，创建一个单一责权封装的小模块，并在其中包括测试文件。将会更容易浏览，更一目了然。
|
||||
@ -377,7 +377,7 @@ JavaScript工程项目的一系列最佳实践策略
|
||||
|
||||
_为什么：_
|
||||
> 当您为不同的目的（数据库，API等）分解不同的配置文件;将它们放在具有容易识别名称（如 `config` ）的文件夹中才是有意义的。请记住不要为不同的环境制作不同的配置文件。这样并不是具有扩展性的做法，如果这样，就会导致随着更多应用程序部署被创建出来，新的环境名称也会不断被创建，非常混乱。
|
||||
配置文件中使用的值应通过环境变量提供。 [更多请阅读...](https://medium.com/@fedorHK/no-config-b3f1171eecd5)
|
||||
> 配置文件中使用的值应通过环境变量提供。 [更多请阅读...](https://medium.com/@fedorHK/no-config-b3f1171eecd5)
|
||||
|
||||
* 将脚本文件放在`./scripts`文件夹中。包括 `bash` 脚本和 `node` 脚本。
|
||||
|
||||
@ -517,7 +517,7 @@ _为什么：_
|
||||
* 我们主要遵循资源导向的设计方式。它有三个主要要素：资源，集合和 URLs。
|
||||
* 资源具有数据，嵌套，和一些操作方法。
|
||||
* 一组资源称为一个集合。
|
||||
* URL标识资源或集合的线上位置。
|
||||
* URL标识资源或集合的线上位置。
|
||||
|
||||
_为什么：_
|
||||
> 这是针对开发人员（您的主要API使用者）非常著名的设计方式。除了可读性和易用性之外，它还允许我们在无需了解API细节的情况下编写通用库和一些连接器。
|
||||
@ -766,7 +766,6 @@ _为什么：_
|
||||
|
||||
确保您有权使用的这些资源。如果您使用其中的软件库，请记住先查询MIT，Apache或BSD（以更好地了解您所能够拥有的权限），但如果您打算修改它们，请查看许可证详细信息。图像和视频的版权可能会导致法律问题。
|
||||
|
||||
|
||||
---
|
||||
资源:
|
||||
[RisingStack Engineering](https://blog.risingstack.com/),
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user