The “master” branch is used to prepare the latest critical bug-fix release.
"master" 分支用于准备最新的关键 bug 修复版本
The “master” branch should always be ready for immediate release.
"master" 分支应该随时准备立即发布
We can’t merge new features or low priority bug fixes directly to master, since they require additional QA efforts and may block the delivery of critical bugfix releases.
我们不能直接将新特性或低优先级的 bug 修复合并到 "master" 分支，因为它们需要额外的质量保证工作，并且可能会阻止关键错误修正版本的交付
The “develop/MAJOR.MINOR” branch (e.g. develop/3.4) is used to prepare the next minor release. This branch should accumulate all non-critical bug fixes and new features with the corresponding fix version.
"development/MAJOR.MINOR" 分支(例如 development/3.4)用于准备下一个次要版本。这个分支应该累积所有非关键的 bug 修复和新特性以及相应的修复版本
The “feature/ISSUE_NUMBER” branch (e.g. feature/5976) is created by Andrew Shvayka, Igor Kulikov, Volodymyr Babak, Vlad Prykhodko or Yevhen Bondarenko upon request. The branch must be created if more than 1 person contributes to the PR.
"Feature/ISSUE _ NUMBER" 分支(例如 Feature/5976)是由 Andrew Shvayka、 Igor Kulikov、 Volodymyr Babak、 Vlad Prykhodko 或 Yevhen Bondarenko 根据请求创建的。如果有超过一个人为 PR 做出贡献，则必须建立该分支
tb 的分支管理
thingsboard 的分支类型包括 master、feature、hotfix 和 release，这基本符合 gitflow 分支模型的设计
gitflow 分支模型如下：
其中每种分支的作用：
master
反映生产就绪状态的主要分支
develop
反映下一个 release 的最新交付开发更改的状态
从 master 分支出来
当 develop（几乎）反映了新发布的期望状态，就 merge 回 release 分支
feature
用于为即将到来或遥远的未来版本开发新功能
从 develop 分支出来
最终必须 merge 回到 develop 分支
release
可能从 develop 分支出来
merge 回 develop 和 master 分支
hotfix
当出现预料之外的 bug 时从 master 分支出来
merge 回 develop 和 master 分支
pull requests
向 CE 提交 PR
Each PR must reference an issue. Use Branch policy to determine the target branch.
每个 PR 必须引用一个 issue。使用上述的分支管理规定去决定目标分支
PR name may contain [WIP] prefix (Work In Progress) but must contain the fix version as well. For example: “[WIP][3.4] Draft of my super feature for internal review by other team members”.
PR 的名称可以包含 [WIP] 前缀，但也必须包含规定版本。比如 "[ WIP ][3.4]我的超级特性草案，供其他团队成员进行内部审查"
对于修复 bug
The Issue must contain valid steps to reproduce, while the PR must contain a description of what and how the bug was fixed.
issue 必须包含有效的步骤来复现，与此同时 PR 必须包含关于 bug 是什么以及如何修复 bug 的描述
UI: Add screen of the bug fix result (e.g. screenshot of the component that was fixed. Add “before” and “after” for best user experience.) whenever it is reasonable.
UI: 只要合理，就添加 bug 修复后的截图（比如被修复的组件的截图。添加 "before" 和 "after" 以获得最佳用户体验）
Back-end: Add corresponding unit and/or integration test(s). Provide a written explanation if you have failed to add tests.
后端: 添加相应的单元测试和/或集成测试。如果您未能添加测试，请提供书面解释。
对于 Feature Request
The PR must include a valid description of the scope of changes. See PR checklist. Feel free to contribute to the “pull_request_template.md” file that is located at the root of the project.
PR 必须包括修改范围内的有效描述。请查看 PR checklist。您可以随意贡献位于项目根目录下的 "pull _ request _ template. md" 文件
Merging from CE to PE
We decided to move from periodic merges from Community Edition(CE) to Professional Edition (PE) performed by Igor Kulikov or Andrew Shvayka to a process, where every internal contributor creates their own PR for ThingsBoard PE
我们决定从由 Igor Kulikov 或 Andrew Shvayka 执行的社区版(CE)到专业版(PE)的定期合并转向一个流程，在这个流程中，每个内部贡献者都为 ThingsBoard PE 创建自己的 PR
==注意：仅限于内部贡献者才能操作 PE 仓库，不是贡献者的话操作 PE 的部分可以不看==
The following commands assume that you are in your local fork of ThingsBoard PE and you have added the fork of the CE repository as a remote called “opensource”. You may check this using the following command:
以下命令假设您在 ThingsBoard PE的本地 fork 中，并且您已将 CE 仓库的 fork 添加为一个名为 "opensource" 的 remote。你可以使用以下指令来检查 remote：
git remote -v
Expected output:
期望得到的输出：
opensource git@github.com:your-github-id/thingsboard.git
origin git@github.com:thingsboard/thingsboard-pe.git
If you don’t have the opensource remote, you may add it
如果你没有 opensource remote，你应该添加它
git remote add opensource git@github.com:your-github-id/thingsboard.git
You must understand the commands below before executing them. You must check your current location using “git remote -v” before pushing your changes to the remote location.
It is very important, in order to avoid accidental push of the PE codebase to the open repository.
在执行以下指令前你必须先了解它们。在 push 你的修改到 remote 位置前你必须使用 "git remote -v" 来检查当前的位置
有用的指令
Check the output to make sure you are in the correct location:
检查输出以确保你在正确的位置：
Check that your remote locations are correctly configured:
检查你的 remote 位置被正确设置：
git remote -v
Check out your local master branch:
检查你本地 master 分支
git checkout master
Create the new branch with the same name as you used in CE:
创建一个和你在 CE 中使用的分支相同名称的新分支
git checkout -b new-feature-name-the-same-as-on-ce
Fetch the latest changes from the PE repository:
从 PE 仓库中拉取最新的更改
git pull origin/master
Push new changes to your fork of the PE repository:
push 新的变更到你 fork 的 PE 仓库
git push origin new-feature-name-the-same-as-on-ce
Fetch the CE fork changes:
拉取 fork 的 CE 更改
git fetch opensource
Merge the CE changes:
merge CE 的更改
git merge opensource/new-feature-name-the-same-as-on-ce
Make sure the new files from CE has valid license headers now:
确保 CE 的新文件现在具有有效的 license header
mvn -T 0.5C license:format clean install -DskipTests
git add -u
Commit the merge if there were conflicts:
如果存在冲突，则 commit merge
git commit
Push the changes to your PE fork:
将更改 push 到你 fork 的 PE 中
git push origin new-feature-name-the-same-as-on-ce
数据库版本管理
thingsboard 在 ThingsboardInstallService.java 设计了数据库版本变更的逻辑，拿其中一个版本更新举例：
case "3.4.1":
log.info("Upgrading ThingsBoard from version 3.4.1 to 3.4.2 ...");
databaseEntitiesUpgradeService.upgradeDatabase("3.4.1");
dataUpdateService.updateData("3.4.1");
log.info("Updating system data...");
systemDataLoaderService.updateSystemWidgets();
break;
首先会调用 upgradeDatabase 方法来读取相应的 sql 文件来更新数据库，并且会在 thingsboard 中用于存储数据库版本号的数据库表 tb_schema_settings 中更新字段 schema_version 的值为最新的数据库版本号
在实际项目更新数据库的操作需要参考此处： github.com/thingsboard…
docs.google.com/document/d/…
nvie.com/posts/a-suc…
nvie.com/files/Git-b…
github.com/thingsboard…
Vacodwave
Markdown
