同步操作将从 DolphinScheduler/DolphinScheduler 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
Pull Request 本质上是一种软件的合作方式,是将涉及不同功能的代码,纳入主干的一种流程。这个过程中,可以进行讨论、审核和修改代码。
在 Pull Request 中尽量不讨论代码的实现方案,代码及其逻辑的大体实现方案应该尽量在 Issue 或者邮件列表中被讨论确定,在 Pull Request 中我们尽量只关注代码的格式以及代码规范等信息,从而避免实现方式的意见不同而导致 waste time。
标题格式:[Pull Request 类型
-Issue 号
][模块名
] Pull Request 描述
其中Pull Request 类型
和Issue 类型
的对应关系如下:
Issue 类型 | Pull Request 类型 | 样例(假设 Issue 号为 3333) |
---|---|---|
Feature | Feature | [Feature-3333][server] Implement xxx |
Bug | Fix | [Fix-3333][server] Fix xxx |
Improvement | Improvement | [Improvement-3333][alert] Improve the performance of xxx |
Test | Test | [Test-3333][api] Add the e2e test of xxx |
Sub-Task | Sub-Task 对应的父类型 | [Feature-3333][server] Implement xxx |
其中 Issue 号
是指当前 Pull Request 对应要解决的 Issue 号,模块名
同 Issue 的模块名。
分支名格式:Pull Request 类型
-Issue 号
,举例:Feature-3333。
请参阅到 commit message 篇。
DolphinScheduler使用Spotless
为您自动修复代码风格和格式问题,
详情见代码风格。
怎样处理一个 Pull Request 对应多个 Issue 的场景。
首先 Pull Request 和 Issue 一对多的场景是比较少的。Pull Request 和 Issue 一对多的根本原因就是出现了多个 Issue 需要做大体相同的一件事情的场景,通常针对这种场景有两种解决方法:第一种就是把多个功能相同的 Issue 合并到同一个 Issue 上,然后把其他的 Issue 进行关闭;第二种就是多个 Issue 大体上是在做一个功能,但是存在一些细微的差别,这类场景下可以把每个 Issue 的职责划分清楚,每一个 Issue 的类型都标记为 Sub-Task,然后将这些 Sub-Task 类型的 Issue 关联到一个总 Issue 上,在提交 Pull Request 时,每个 Pull Request 都只关联一个 Sub-Task 的 Issue。
尽量把一个 Pull Request 作为最小粒度。如果一个 Pull Request 只做一件事,Contributor 容易完成,Pull Request 影响的范围也会更加清晰,对 reviewer 的压力也会小。
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。