同步操作将从 ApacheLinkis/linkis 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
更多信息可以见官网如何参与项目贡献
非常感谢贡献Linkis项目!在参与贡献之前,请仔细阅读以下指引。
我们建议无论是 Bug 反馈还是修复,都先创建一个 Issue 来仔细描述 Bug 的状况,以助于社区可以通过 Issue 记录来找到和回顾问题以及代码。Bug 反馈 Issue 通常需要包含完整描述 Bug 的信息以及可复现的场景,这样社区才能快速定位导致 Bug 的原因并修复它。包含 #bug
标签的打开的 Issue 都是需要被修复的。
在交流过程中,详细描述新功能(或重构)的细节、机制和使用场景,能够促使它更好更快地被实现(包括测试用例和代码,及CI/CD相关工作)。如果计划实现一个重大的功能(或重构),请务必通过 Issue 或其他方式与核心开发团队进行沟通,这样大家能以最效率的方式来推进它。包含 #feature
标签的打开的 Issue 都是需要被实现的新功能,包含 #enhancement
标签打开的 Issue 都是需要改进重构的功能。
帮助回答 Issue 中的使用问题是为 Linkis 社区做贡献的一个非常有价值的方式;社区中总会有新用户不断进来,在帮助新用户的同时,也可以展现您的专业知识。
Linkis 文档位于Linkis官网 ,文档的补充完善对于Linkis 的发展也至关重要。
包括参与和帮助组织社区交流、社区运营活动等,其他能够帮助Linkis 项目和社区的活动。
Linkis 源码可能会产生一些临时分支,但真正有明确意义的只有以下三个分支:
场景:Upstream仓库有新增分支,但是fork的库没有该分支(可以选择删除后,重新fork,但是会丢失未merge到原始仓库的变更)
在自己clone的本地项目中操作
git remote add apache git@github.com:apache/incubator-linkis.git
git fetch apache
git checkout -b dev-1.1.4 apache/dev-1.1.4
git push origin dev-1.1.4:dev-1.1.4
git remote remove apache
git pull
step1 确认当前开发的基础分支(一般是当前进行的中版本,如当前社区开发中的版本1.1.0,那么分支就是dev-1.1.0,不确定的话可以在社区群里问下或则在issue中@相关同学)
step2 同步Upstream仓库分支最新代码到自己的Fork仓库 分支,参见指引 [2.1.2 同步Upstream仓库分支最新代码到自己的Fork仓库 ]
step3 基于开发分支,拉取新fix/feature分支(不要直接在原分支上修改,如果后续pr以squash方式merge后,提交的commit记录会被合并成一个)
git checkout -b dev-1.1.4-fix dev-1.1.4
git push origin dev-1.1.4-fix:dev-1.1.4-fix
[WIP] Dev 1.1.1 Add junit test code for [linkis-common]
;关联对应的issue等)git branch -d dev-1.1.4-fix
git push
请注意:大特性的dev分支,在命名时除了版本号,还会加上相应的命名说明,如:dev-0.10.0-flink,指0.10.0的flink特性开发分支。
Linkis 前后端代码共用同一个代码库,但在开发上是分离的。在着手开发之前,请先将 Linkis 项目 fork 一份到自己的 Github Repositories 中, 开发时请基于自己 Github Repositories 中的 Linkis 代码库进行开发。
我们建议克隆dev分支命名为dev-fix来开发,同时在自己仓库新建dev-fix分支,直接在原分支上修改,如果后续pr以squash方式merge后,提交的commit记录会被合并成一个
#拉取分支
git clone https://github.com/{githubid}/incubator-linkis.git --branch dev
#根据dev生成本地dev-fix分支
git checkout -b dev-fix dev
#把本地dev-fix分支推到自己的仓库
git push origin dev-fix dev-fix
<type>(<scope>): <subject>
原则,详情可以参考阮一峰的 Commit message 和 Change log 编写指南 这篇文章。在贡献代码之前,可以了解一下什么样的提交在 Review 中是受欢迎的。简单来说,如果一项提交能带来尽可能多增益和尽可能少的副作用或风险,那它被合并的几率就越高,Review 的速度也会越快。风险大、价值低的提交是几乎不可能被合并的,并且有可能会被拒绝 Review。
如果您对 Linkis 提过颇具价值的 PR 并且被合并,或是连续贡献超过半年,且至少主导过一次版本的发布,您可以通过官方微信群找到Linkis项目的一个 PMC ,如果他愿意提名您为 committer,并愿意为您陈述您的贡献给所有 PMC和Committer,那么接下来会发起一次投票;PMC和其他 Committers 将会一起投票决定是否允许您的加入,如果得到足够票数,您将成为 Linkis 项目的 Committer。
如果您是 Linkis 项目的 Committer,并且您贡献的所有内容得到了其他 Committee 成员的认可,您可以申请成为 Linkis Committee 成员,其他 Committee 成员将会一起投票决定是否允许您的加入,如果全票通过,您将成为 Linkis Committee 成员。
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。