Lean 引擎贡献指南从 Fork、分支模型到合并的完整协作工作流【免费下载链接】LeanLean Algorithmic Trading Engine by QuantConnect (Python, C#)项目地址: https://gitcode.com/GitHub_Trending/le/LeanQuantConnect Lean 是一个以 C# 为核心并深度支持 Python的开源量化交易引擎本文基于仓库根目录下的 CONTRIBUTING.md完整讲解外部贡献者Contributor与内部协作者Collaborator如何围绕 Lean 开展协作包括代码风格与测试门槛、Algorithm Framework 模块的特殊贡献约束、Fork/Upstream 的初始化配置、master 主分支与 topic 分支的维护策略以及从创建分支、提交、rebase 到提交 Pull Request 的完整实战命令。读完本文你将能够以符合 Lean 项目规范的方式提交第一个高质量 PR。一、角色模型Collaborator 与 ContributorLean 仓库的贡献流程围绕两类角色展开Collaborator协作者拥有 Lean 仓库写权限的人职责是评审并合并来自贡献者的 Pull Request。Contributor贡献者任何人——包括正在阅读本文的你。贡献者通过 Fork 仓库、开发功能或修复 bug、提交 PR 的方式参与项目。这一分工决定了整个 Git 协作模型贡献者只在自己的 Forkorigin上工作最终通过 PR 将改动合并进上游主仓upstream/master而合并动作由协作者完成。二、代码风格与测试要求提交前的硬性门槛代码评审者会依据Microsoft 的 C# 编码规范来审查代码因此贡献者的代码必须符合以下约定遵循 Microsoft C# 指南命名、成员布局、注释规范等使用 4 个空格作为软缩进soft tabs确保文件在不同人的编辑器与 diff 工具中都能正确渲染每个 PR 必须附带单元测试新功能测试应覆盖预期使用场景以及适用的边界情况edge casesBug 修复测试必须能够暴露复现所修复的 bug。仓库实际配置印证了这些约定根目录的 .editorconfig 明确规定indent_size 4、indent_style space、charset utf-8、insert_final_newline true而对*.{js,yml,json,config,csproj}文件使用 2 空格缩进.sh脚本使用 LF 换行。例如 Algorithm.Framework/QuantConnect.Algorithm.Framework.csproj 中还开启了AnalysisModeAllEnabledByDefault/AnalysisMode即所有静态分析规则默认启用编译器会帮助评审者自动拦截大量风格与质量问题。测试代码集中在 Tests 目录其中 Tests/Algorithm/Framework 下为每个框架模块Alphas、Execution、Portfolio、Risk、Selection 等都建立了对应的*Tests.cs测试文件。三、Algorithm Framework 模块贡献的额外约束由于 Lean 的 Algorithm Framework 模块会被量化用户直接复用到自己的策略中贡献此类模块需要遵守额外的模式1. 单一职责原则模块应当只专注做好一个聚焦、具体的角色。例如把风控逻辑与通知notifications混在一起、或在执行模型之外直接下单都违反了关注点分离separation of concerns这一通用编程原则。如果希望提供额外功能应通过添加事件处理器event handlers让用户从自己的 Algorithm 实例中绑定而不是把多种职责塞进同一个模块。源码中可以看到这一原则的落地例如 Algorithm.Framework/Alphas/ConstantAlphaModel.cs 只负责为每个证券生成固定方向的 Insight通过Update方法产出并在OnSecuritiesChanged中维护证券集合Algorithm.Framework/Execution/StandardDeviationExecutionModel.cs 只负责判断价格偏离均值多少个标准差后提交市价单两个模块各司其职。2. 生产代码保持静默默认情况下生产代码应保持静默除非发生致命异常。因此不允许在 LEAN 框架模块内部使用日志或调试输出logging/debugging不允许在模块内部添加额外绘图charting因为它会消耗资源。以 Algorithm.Framework/Execution/StandardDeviationExecutionModel.cs 为例整个执行流程Execute中按保证金影响排序目标、计算未成交数量、检查STD.IsReady与价格是否有利、提交MarketOrder没有任何日志或图表调用符合生产代码静默的约定。四、初始设置Fork、Clone 与 Upstream 配置开始贡献之前需要完成以下初始化步骤注册一个代码托管平台账号Fork 当前 Lean 仓库到自己的账号下将 Fork 克隆到本地。$ git clone https://gitcode.com/GitHub_Trending/le/Lean.git进入 Lean 目录并把上游主仓添加为远程分支remote$ cd Lean $ git remote add upstream https://gitcode.com/GitHub_Trending/le/Lean.gitupstream远程分支将你的 Fork 与主仓库的 master 副本关联起来。之后执行git pull --rebase时你获取的就是主仓库的最新更新。五、保持本地 master 与上游同步配置好 upstream 之后可以用以下命令刷新本地 master$ git checkout master $ git pull --rebase该命令先切换到本地 master 分支再从 upstream 合并最新变更。项目使用rebase而不是 merge 来减少合并提交merge commit带来的噪声保持提交历史的线性与整洁。六、分支模型三个仓库与两类分支1. 三个仓库角色Lean 使用如下命名区分不同仓库名称含义upstream官方的 QuantConnect Lean 主仓库origin你在自己账号下的 Fork 仓库local你本地对 origin 的克隆作为contributor你把完成的本地 topic 分支推送到origin并从upstream拉取更新作为collaborator有写权限你把贡献者的分支合并进upstream。2. 主分支Primary Branchupstream 仓库只维护一条主分支upstream/master—— 所有主要开发工作都发生在这里。3. 主题分支Topic BranchesTopic 分支是贡献者开发 bug 修复与新功能的载体便于之后轻松合并到 master。它必须遵守几条简单规则必须从master分支出来必须合并回master建议在分支名中包含 GitHub issue 编号。Topic 分支只应存在于你的local和origin仓库中。提交 Pull Request 时请求的就是把你的 topic 分支合并到upstream/master。七、完整贡献工作流从创建分支到 PR 合入步骤 1创建 topic 分支为将要进行的工作创建新分支命名遵循以下约定bug-issue#-descriptionbug 修复feature-issue#-description新功能$ git checkout -b bug-123-short-issue-description Switched to a new branch bug-123-short-issue-description步骤 2提交前自查与提交进行开发后提交变更。提交前务必先审查自己的改动$ git status $ git diff $ git add --all $ git commit提交信息请遵循良好的提交描述实践说明为什么和做了什么。步骤 3推送 topic 分支到 Fork$ git push origin bug-123-short-issue-description步骤 4与 upstream/master 保持同步完成一部分工作后需要合并 upstream/master 的变更。使用下面两条命令辅助上游合并$ git fetch upstream $ git rebase upstream/master bug-123-short-issue-descriptiongit fetch upstream只把 upstream 仓库下载到本地不会自动合并git rebase upstream/master bug-123-short-issue-description把你的改动 rebase 到 upstream/master 之上使评审者collaborators更容易审查。⚠️ CAUTION重要警告一旦分支已推送到远程绝对不要 rebase如果分支推送后还需要合并上游变更应使用$ git pull upstream master步骤 5提交 Pull Requesttopic 分支开发完成并准备评审后推送回 origin$ git push origin bug-123-short-issue-description To gitgithub.com:username/Lean.git * [new branch] bug-123-short-issue-description - bug-123-short-issue-description现在就可以从该分支向upstream/master发起 Pull Request并在 issue 跟踪器中更新状态让协作者知道你的分支已准备好被评审和合并。仓库在 .github/pull_request_template.md 提供了标准 PR 模板其中 checklist 明确要求代码符合项目代码风格、已阅读CONTRIBUTING文档、添加了覆盖改动的测试、所有新旧测试通过、分支遵循bug-issue#-description或feature-issue#-description命名约定。步骤 6根据评审意见迭代如果评审过程中要求额外修改请在原来的 topic 分支上修改并重新推送。首先重新检出最初开发的分支$ git checkout bug-123-short-issue-description然后回应评审意见、提交并重新推送$ git add --all $ git commit $ git push八、CI 与回归测试质量保障的最后一道防线虽然 CONTRIBUTING.md 主要约束的是开发者侧的工作流仓库还通过 .github/workflows 下的多个 GitHub Actions 流水线把质量门槛自动化regression-tests.yml运行全套回归测试、syntax-tests.yml校验算法语法、benchmarks.yml与research-regression-tests.yml分别负责性能基准与科研场景回归配合 PR 模板中的 checklist共同确保每个合入 upstream/master 的改动都经过单元测试与回归验证。总结Lean 的贡献流程可以浓缩为一句话在 Forkorigin上的 topic 分支开发从 upstream 拉取更新用 rebase 保持历史整洁通过 PR 合入 upstream/master。遵守 4 空格缩进、Microsoft C# 风格、必带单元测试、框架模块保持单一职责且生产代码静默这几条铁律再结合规范的bug-issue#-description/feature-issue#-description分支命名你的第一个 Lean PR 就能顺畅地通过评审与 CI 检验。【免费下载链接】LeanLean Algorithmic Trading Engine by QuantConnect (Python, C#)项目地址: https://gitcode.com/GitHub_Trending/le/Lean创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Lean 引擎贡献指南：从 Fork、分支模型到合并的完整协作工作流
Lean 引擎贡献指南从 Fork、分支模型到合并的完整协作工作流【免费下载链接】LeanLean Algorithmic Trading Engine by QuantConnect (Python, C#)项目地址: https://gitcode.com/GitHub_Trending/le/LeanQuantConnect Lean 是一个以 C# 为核心并深度支持 Python的开源量化交易引擎本文基于仓库根目录下的 CONTRIBUTING.md完整讲解外部贡献者Contributor与内部协作者Collaborator如何围绕 Lean 开展协作包括代码风格与测试门槛、Algorithm Framework 模块的特殊贡献约束、Fork/Upstream 的初始化配置、master 主分支与 topic 分支的维护策略以及从创建分支、提交、rebase 到提交 Pull Request 的完整实战命令。读完本文你将能够以符合 Lean 项目规范的方式提交第一个高质量 PR。一、角色模型Collaborator 与 ContributorLean 仓库的贡献流程围绕两类角色展开Collaborator协作者拥有 Lean 仓库写权限的人职责是评审并合并来自贡献者的 Pull Request。Contributor贡献者任何人——包括正在阅读本文的你。贡献者通过 Fork 仓库、开发功能或修复 bug、提交 PR 的方式参与项目。这一分工决定了整个 Git 协作模型贡献者只在自己的 Forkorigin上工作最终通过 PR 将改动合并进上游主仓upstream/master而合并动作由协作者完成。二、代码风格与测试要求提交前的硬性门槛代码评审者会依据Microsoft 的 C# 编码规范来审查代码因此贡献者的代码必须符合以下约定遵循 Microsoft C# 指南命名、成员布局、注释规范等使用 4 个空格作为软缩进soft tabs确保文件在不同人的编辑器与 diff 工具中都能正确渲染每个 PR 必须附带单元测试新功能测试应覆盖预期使用场景以及适用的边界情况edge casesBug 修复测试必须能够暴露复现所修复的 bug。仓库实际配置印证了这些约定根目录的 .editorconfig 明确规定indent_size 4、indent_style space、charset utf-8、insert_final_newline true而对*.{js,yml,json,config,csproj}文件使用 2 空格缩进.sh脚本使用 LF 换行。例如 Algorithm.Framework/QuantConnect.Algorithm.Framework.csproj 中还开启了AnalysisModeAllEnabledByDefault/AnalysisMode即所有静态分析规则默认启用编译器会帮助评审者自动拦截大量风格与质量问题。测试代码集中在 Tests 目录其中 Tests/Algorithm/Framework 下为每个框架模块Alphas、Execution、Portfolio、Risk、Selection 等都建立了对应的*Tests.cs测试文件。三、Algorithm Framework 模块贡献的额外约束由于 Lean 的 Algorithm Framework 模块会被量化用户直接复用到自己的策略中贡献此类模块需要遵守额外的模式1. 单一职责原则模块应当只专注做好一个聚焦、具体的角色。例如把风控逻辑与通知notifications混在一起、或在执行模型之外直接下单都违反了关注点分离separation of concerns这一通用编程原则。如果希望提供额外功能应通过添加事件处理器event handlers让用户从自己的 Algorithm 实例中绑定而不是把多种职责塞进同一个模块。源码中可以看到这一原则的落地例如 Algorithm.Framework/Alphas/ConstantAlphaModel.cs 只负责为每个证券生成固定方向的 Insight通过Update方法产出并在OnSecuritiesChanged中维护证券集合Algorithm.Framework/Execution/StandardDeviationExecutionModel.cs 只负责判断价格偏离均值多少个标准差后提交市价单两个模块各司其职。2. 生产代码保持静默默认情况下生产代码应保持静默除非发生致命异常。因此不允许在 LEAN 框架模块内部使用日志或调试输出logging/debugging不允许在模块内部添加额外绘图charting因为它会消耗资源。以 Algorithm.Framework/Execution/StandardDeviationExecutionModel.cs 为例整个执行流程Execute中按保证金影响排序目标、计算未成交数量、检查STD.IsReady与价格是否有利、提交MarketOrder没有任何日志或图表调用符合生产代码静默的约定。四、初始设置Fork、Clone 与 Upstream 配置开始贡献之前需要完成以下初始化步骤注册一个代码托管平台账号Fork 当前 Lean 仓库到自己的账号下将 Fork 克隆到本地。$ git clone https://gitcode.com/GitHub_Trending/le/Lean.git进入 Lean 目录并把上游主仓添加为远程分支remote$ cd Lean $ git remote add upstream https://gitcode.com/GitHub_Trending/le/Lean.gitupstream远程分支将你的 Fork 与主仓库的 master 副本关联起来。之后执行git pull --rebase时你获取的就是主仓库的最新更新。五、保持本地 master 与上游同步配置好 upstream 之后可以用以下命令刷新本地 master$ git checkout master $ git pull --rebase该命令先切换到本地 master 分支再从 upstream 合并最新变更。项目使用rebase而不是 merge 来减少合并提交merge commit带来的噪声保持提交历史的线性与整洁。六、分支模型三个仓库与两类分支1. 三个仓库角色Lean 使用如下命名区分不同仓库名称含义upstream官方的 QuantConnect Lean 主仓库origin你在自己账号下的 Fork 仓库local你本地对 origin 的克隆作为contributor你把完成的本地 topic 分支推送到origin并从upstream拉取更新作为collaborator有写权限你把贡献者的分支合并进upstream。2. 主分支Primary Branchupstream 仓库只维护一条主分支upstream/master—— 所有主要开发工作都发生在这里。3. 主题分支Topic BranchesTopic 分支是贡献者开发 bug 修复与新功能的载体便于之后轻松合并到 master。它必须遵守几条简单规则必须从master分支出来必须合并回master建议在分支名中包含 GitHub issue 编号。Topic 分支只应存在于你的local和origin仓库中。提交 Pull Request 时请求的就是把你的 topic 分支合并到upstream/master。七、完整贡献工作流从创建分支到 PR 合入步骤 1创建 topic 分支为将要进行的工作创建新分支命名遵循以下约定bug-issue#-descriptionbug 修复feature-issue#-description新功能$ git checkout -b bug-123-short-issue-description Switched to a new branch bug-123-short-issue-description步骤 2提交前自查与提交进行开发后提交变更。提交前务必先审查自己的改动$ git status $ git diff $ git add --all $ git commit提交信息请遵循良好的提交描述实践说明为什么和做了什么。步骤 3推送 topic 分支到 Fork$ git push origin bug-123-short-issue-description步骤 4与 upstream/master 保持同步完成一部分工作后需要合并 upstream/master 的变更。使用下面两条命令辅助上游合并$ git fetch upstream $ git rebase upstream/master bug-123-short-issue-descriptiongit fetch upstream只把 upstream 仓库下载到本地不会自动合并git rebase upstream/master bug-123-short-issue-description把你的改动 rebase 到 upstream/master 之上使评审者collaborators更容易审查。⚠️ CAUTION重要警告一旦分支已推送到远程绝对不要 rebase如果分支推送后还需要合并上游变更应使用$ git pull upstream master步骤 5提交 Pull Requesttopic 分支开发完成并准备评审后推送回 origin$ git push origin bug-123-short-issue-description To gitgithub.com:username/Lean.git * [new branch] bug-123-short-issue-description - bug-123-short-issue-description现在就可以从该分支向upstream/master发起 Pull Request并在 issue 跟踪器中更新状态让协作者知道你的分支已准备好被评审和合并。仓库在 .github/pull_request_template.md 提供了标准 PR 模板其中 checklist 明确要求代码符合项目代码风格、已阅读CONTRIBUTING文档、添加了覆盖改动的测试、所有新旧测试通过、分支遵循bug-issue#-description或feature-issue#-description命名约定。步骤 6根据评审意见迭代如果评审过程中要求额外修改请在原来的 topic 分支上修改并重新推送。首先重新检出最初开发的分支$ git checkout bug-123-short-issue-description然后回应评审意见、提交并重新推送$ git add --all $ git commit $ git push八、CI 与回归测试质量保障的最后一道防线虽然 CONTRIBUTING.md 主要约束的是开发者侧的工作流仓库还通过 .github/workflows 下的多个 GitHub Actions 流水线把质量门槛自动化regression-tests.yml运行全套回归测试、syntax-tests.yml校验算法语法、benchmarks.yml与research-regression-tests.yml分别负责性能基准与科研场景回归配合 PR 模板中的 checklist共同确保每个合入 upstream/master 的改动都经过单元测试与回归验证。总结Lean 的贡献流程可以浓缩为一句话在 Forkorigin上的 topic 分支开发从 upstream 拉取更新用 rebase 保持历史整洁通过 PR 合入 upstream/master。遵守 4 空格缩进、Microsoft C# 风格、必带单元测试、框架模块保持单一职责且生产代码静默这几条铁律再结合规范的bug-issue#-description/feature-issue#-description分支命名你的第一个 Lean PR 就能顺畅地通过评审与 CI 检验。【免费下载链接】LeanLean Algorithmic Trading Engine by QuantConnect (Python, C#)项目地址: https://gitcode.com/GitHub_Trending/le/Lean创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考