yfinance 代码开发与贡献指南双层分支模型、PR 提交流程与 Git 实战技巧【免费下载链接】yfinanceDownload market data from Yahoo! Finances API项目地址: https://gitcode.com/GitHub_Trending/yf/yfinance本文是 yfinance一个用于从 Yahoo! Finance API 下载市场数据的 Python 库开发者指南的核心章节解读围绕 doc/source/development/code.rst 展开完整讲解该项目dev main 双层分支模型的设计动机与例外规则、从 Fork 到提交 Pull Request 的完整流程、如何在本机运行任意分支的代码以及 rebase / squash / force-with-lease 等保持提交历史整洁的 Git 技巧。读完本文你将能按 yfinance 官方规范提交高质量补丁并理解其 CI/CD 流水线文档发布、PyPI 发布与分支模型的对应关系。一、为什么需要双层分支模型dev 与 main 的职责分工yfinance 是一个依赖社区持续调查 bug、贡献代码的开源项目见 CONTRIBUTING.md 开篇说明。为了让新功能快速迭代、又不会破坏线上稳定版本项目采用了一套两层分支two-layer branch model策略dev新功能new features和大部分 bug 修复bug fixes都合并到这个分支。所有改动在这里进行集体测试collective testing、**冲突解决conflict resolution**和进一步稳定化直到可以合入稳定分支main稳定分支stable branch**PIP 发布PIP releases**只从该分支产生。上图doc/source/development/assets/branches.png直观展示了这一模型上方main分支沿线分布v1、v1.1、v2、v3等发布节点v1上标注了 urgent / bugfixes 的紧急修复下方dev分支承载 feature 1、bugfixes、feature 2 等开发任务通过虚线合入点回流到 main 的v2、v3。该图与文档中的说明互为印证所有开发工作先在 dev 上汇合、稳定再以版本形式进入 main。分支目标与默认行为默认情况下By default分支目标target指向main但大多数贡献应指向 dev。这句话的含义是在 GitHub 上发起 Pull Request 时仓库默认的合并目标分支是 main但按照项目约定普通的功能开发和 bug 修复都应当把 PR 指向 dev而不是 main。这与多数主干开发型仓库的习惯相反是 yfinance 为了兼顾稳定性与迭代速度而做的刻意设计。允许直接合入 main 的例外情况文档明确列出了三类可以直接向 main 发起合并Direct merges to main的例外yfinance 大规模损坏yfinanceis massively broken——例如整个库无法导入、核心 API 全部失效需要紧急止血部分功能损坏且修复简单、隔离Part ofyfinanceis broken, and the fix is simple and isolated——修复只影响单一模块、风险可控无需经过 dev 的长时间集成测试不改动代码的变更Not updating the code, e.g. docs——纯文档docs更新不会影响运行时行为可以直接合入 main。从仓库的实际 CI/CD 配置可以进一步印证分支与发布流程的对应关系见下文与分支模型对应的工程流水线一节main 是唯一被自动化流程监听的分支。二、创建你的开发分支Fork → Clone → Branch → Commit → Push → PR文档给出的完整流程如下共六个步骤。其中第 1 步在 GitHub 网页端完成其余为本地 Git 操作。1. Fork 仓库并同步在 GitHub 上 Fork yfinance 仓库。如果之前已经 Fork 过记得先点击Sync fork同步确保你的 Fork 与上游一致避免基于过期的代码开发。2. 克隆你的 Forkgit clone https://github.com/{user}/{repo}.git其中{user}是你的 GitHub 用户名{repo}是你的 Fork 仓库名。3. 从合适的基分支创建新分支git checkout {base e.g. dev} git pull git checkout -b {your branch}关键点在于基分支base branch的选择根据上文的分支模型功能开发和常规 bug 修复应以dev为基只有文档更新或紧急修复才考虑以main为基。先git checkout到基分支并git pull拉取最新再git checkout -b从它派生出你自己的工作分支这样后续的 PR diff 会最小、最干净。4. 提交变更并推送git commit -m short sentence summary -m full commit message # Long message can be multiple lines (tip: copy-paste)为了让提交历史和 GitHub 的network graph网络图保持紧凑提交信息被要求采用一句简短摘要 完整说明的双段式结构第一条-m是短句摘要short sentence summary第二条-m是完整提交信息full commit message可以多行、可以直接粘贴较长说明。这种写法既让git log --oneline一目了然又保留了完整的上下文避免长标题挤爆网络图。5. 发起 Pull Request在 GitHub 上Open a pull request将你的 Fork 分支合并到上游仓库。PR 的合并目标base按第一部分的分支模型选择默认是 main但大多数贡献应指向 dev。如果是修复某个 Issue建议在 PR 描述中关联该 Issue 编号见 CONTRIBUTING.md 的建议。说明原文档编号跳过了 5直接在步骤 4 之后标注了 6。本文按实际操作顺序重新编号为 1–5内容与原文完全一致。三、运行一个分支本地安装与验证贡献代码前通常需要在本地跑通目标分支。文档将这一部分指引到专门的运行指南页面原文档中的链接.../development/running.html对应当前仓库的 doc/source/development/running.rst这里综合两处内容给出完整方案。方式一直接用 pip 安装某分支pip install githttps://github.com/{user}/{repo}.git{branch}例如安装某个 feature 分支pip install githttps://github.com/ranaroussi/yfinance.gitfeature/name这种方式的优点是一行命令、即装即用适合快速试用别人的分支缺点是无法直接修改源码。方式二克隆源码并以可编辑模式安装推荐用于开发git clone https://github.com/ranaroussi/yfinance.git cd yfinance pip install -e .[dev]如果要安装特定分支git clone -b {branch} https://github.com/ranaroussi/yfinance.git cd yfinance pip install -e .[dev]其中-e是可编辑安装editable install源码改动即时生效.[dev]会一并安装开发依赖。这些开发依赖定义在 pyproject.toml 的[project.optional-dependencies] dev段包含pytest9.0.3与pytest-cov7.1.0——单元测试与覆盖率ruff0.15.16——Python 代码静态检查lintersphinx8.0.2、pydata-sphinx-theme0.15.4、sphinx-copybutton0.5.2、jinja23.1.4——Sphinx 文档构建工具链。让 Python 找到你的本地源码仅全局安装时需要文档特别加了一个 NOTE只有当你准备全局安装而非针对单个项目时才需要执行这一步如果是在某个项目目录里使用可以跳过直接在项目目录git clone即可。两种做法任选其一把下载目录加入PYTHONPATH环境变量在 Python 文件顶部插入路径import sys sys.path.insert(0, path/to/downloaded/yfinance)验证安装import yfinance print(yfinance)输出应当指向你下载的源码目录module yfinance from path/to/downloaded/yfinance/yfinance/__init__.py如果输出变成了site-packages下的路径如module yfinance from .../lib/python3.10/site-packages/yfinance/__init__.py说明第 2 步路径设置没有生效Python 导入的是已安装的发布版而不是你的本地分支。四、Git 实战技巧rebase、squash 与 force-with-lease这是 doc/source/development/code.rst 的 Git stuff 小节也是被 CONTRIBUTING.md 单独摘录为 Git tricks 的重点内容目的是保持提交历史和 network graph 紧凑、避免未来合并冲突。技巧一把分支从 main 基底迁移到 devrebase --onto在评审 PR 时维护者可能会要求把你的分支从main基底迁移到dev因为按分支模型大多数 PR 应以 dev 为目标。文档给出的完整命令序列是# 1) 先更新所有涉及的分支 git checkout main git pull git checkout dev git pull # 2) 把 {your branch} 从 main 基底重放到 dev 之上 git checkout {your branch} git pull git rebase --onto dev main {your branch} git push --force-with-lease origin {your branch}git rebase --onto dev main {your branch}的含义是把{your branch}中从main分叉出来的所有提交全部剪切并重放到dev的最新提交之上。它不会产生 merge 提交历史保持线性。注意必须更新所有涉及的分支main、dev、你的分支否则基底不完整会导致 rebase 失败或结果错误。技巧二用 rebase 而不是 merge 来同步基分支的新提交git checkout {base branch e.g. dev} git pull git checkout {your branch} git rebase {base} git push --force-with-lease origin {your branch}git rebase可以把你分支上没有的新基分支提交接到你的分支上而不会像git merge那样在你的分支历史里额外增加一个合并提交。文档明确解释了这样做的收益让历史保持干净keeps history clean、避免未来的合并问题avoids future merge problems。技巧三用 interactive rebase 做 squash 合并提交对于微小的、可以忽略的提交tiny or negligible commits应当用 squash 把它们与有意义的提交合并对于一连串连续的同类提交也应当合并成一个。这是保持 PR 可读性的关键。git rebase -i HEAD~2 git push --force-with-lease origin {your branch}git rebase -i HEAD~2会打开交互式编辑器列出最近 2 个提交把后面一个的pick改为squash或s即可合并进前一个。操作完成后同样用git push --force-with-lease推送。为什么始终使用 --force-with-lease 而不是 --force文档在以上所有需要改写历史的场景中都统一使用git push --force-with-lease origin {your branch}--force-with-lease只在你本地所知的远端状态与远端实际状态一致时才允许强制推送如果有人在你上次 fetch 之后又推送了新提交它就会拒绝推送并报错。这比裸--force安全得多能避免覆盖协作伙伴的提交。五、与分支模型对应的工程流水线CI/CD 印证yfinance 的自动化流水线配置在 .github/workflows 目录下它们恰好验证了 main 稳定 发布 这一分支模型定位python-publish.yml监听 GitHubrelease 事件release: types: [created]自动python -m build构建 wheel/sdist 并用 twine 上传到 PyPI。这与文档中main 是产生 PIP 发布的分支完全对应——release 是从 main 打 tag 的deploy_doc.yml监听对main 分支的 pushbranches: [main]自动执行pip install -e .[dev]与sphinx-build -b html doc/source doc/_build/html -v再把生成的 HTML 部署到documentation分支。这与 doc/source/development/documentation.rst 中合入 main 触发文档自动构建的描述一致——所以纯文档变更被允许直接合入 main正是为了尽快触发文档站点更新ruff.yml与pyright.yml对代码做静态检查。其中 ruff 的规则集在 ruff.toml 中固定为E4/E7/E9/F并排除自动生成的yfinance/pricing_pb2.py以保证 CI 结果跨 ruff 版本确定pytest.yml.disabled测试工作流当前处于禁用状态与 doc/source/development/testing.rst 中现有测试已有一定数量失败/错误的现状相符这也正是文档强调大多数贡献应先合入 dev 集体测试、冲突解决后再进 main的实践背景。因此本文第一部分的分支模型不只是纸面约定它直接决定了仓库的文档发布、PyPI 发布与代码质量检查三条自动化流水线的触发条件。六、合入前的工程检查测试与代码规范在向 dev 提交 PR 之前建议在本地完成两项工程检查详见 doc/source/development/testing.rst运行单元测试yfinance 的测试写在tests/目录下如 tests/test_prices.py、tests/test_ticker.py 等二十余个测试文件另有tests/data/存放行情修复测试的 CSV 数据。安装开发依赖后# 运行全部测试 pytest # 运行单个文件 pytest tests/test_prices.py # 运行指定测试类::方法 pytest tests/test_prices.py::TestPriceRepair::test_ticker_missing注意原文档特别提示当前仓库中的测试已存在一定数量的失败/错误Failures: 11、Errors: 93、Skipped: 1 左右这一现状正在持续改善中如果你的改动恰好命中了失败项请留意是否是既有问题而非你的回归。静态检查运行ruff配置见 ruff.toml确保新增代码不引入 E4/E7/E9/F 类问题若涉及类型标注也可参考 pyproject.toml 中[tool.pyright]的 basic 模式配置自查。七、小结贡献 yfinance 的黄金流程综合 doc/source/development/code.rst 及其关联页面向 yfinance 贡献代码的完整路径是选对分支常规功能与 bug 修复 → 基分支选dev紧急修复 / 大规模故障 / 纯文档 → 才考虑直接面向main走对流程Fork → Sync fork → Clone →git checkout -b→ 双段式 commit message → push → Open PR目标分支按模型选择本地验证用pip install git...{branch}或git clone -b {branch}pip install -e .[dev]跑通分支确认import yfinance指向本地源码保持历史整洁用git rebase --onto dev main {your branch}迁移基底、用git rebase {base}同步更新、用git rebase -i HEAD~2做 squash统一以git push --force-with-lease origin {your branch}推送改写后的历史通过工程检查运行 pytest 与 ruff必要时按 doc/source/development/documentation.rst 更新对应文档Sphinx 构建命令为sphinx-build -b html doc/source doc/_build/html可配合python -m http.server -d ./doc/_build/html本地预览。遵循这套规范你的贡献既能快速进入 dev 集体测试也不会给 main 的稳定发布带来风险——这正是 yfinance 双层分支模型要达成的最终目标。【免费下载链接】yfinanceDownload market data from Yahoo! Finances API项目地址: https://gitcode.com/GitHub_Trending/yf/yfinance创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 yfinance 代码开发与贡献指南：双层分支模型、PR 提交流程与 Git 实战技巧
yfinance 代码开发与贡献指南双层分支模型、PR 提交流程与 Git 实战技巧【免费下载链接】yfinanceDownload market data from Yahoo! Finances API项目地址: https://gitcode.com/GitHub_Trending/yf/yfinance本文是 yfinance一个用于从 Yahoo! Finance API 下载市场数据的 Python 库开发者指南的核心章节解读围绕 doc/source/development/code.rst 展开完整讲解该项目dev main 双层分支模型的设计动机与例外规则、从 Fork 到提交 Pull Request 的完整流程、如何在本机运行任意分支的代码以及 rebase / squash / force-with-lease 等保持提交历史整洁的 Git 技巧。读完本文你将能按 yfinance 官方规范提交高质量补丁并理解其 CI/CD 流水线文档发布、PyPI 发布与分支模型的对应关系。一、为什么需要双层分支模型dev 与 main 的职责分工yfinance 是一个依赖社区持续调查 bug、贡献代码的开源项目见 CONTRIBUTING.md 开篇说明。为了让新功能快速迭代、又不会破坏线上稳定版本项目采用了一套两层分支two-layer branch model策略dev新功能new features和大部分 bug 修复bug fixes都合并到这个分支。所有改动在这里进行集体测试collective testing、**冲突解决conflict resolution**和进一步稳定化直到可以合入稳定分支main稳定分支stable branch**PIP 发布PIP releases**只从该分支产生。上图doc/source/development/assets/branches.png直观展示了这一模型上方main分支沿线分布v1、v1.1、v2、v3等发布节点v1上标注了 urgent / bugfixes 的紧急修复下方dev分支承载 feature 1、bugfixes、feature 2 等开发任务通过虚线合入点回流到 main 的v2、v3。该图与文档中的说明互为印证所有开发工作先在 dev 上汇合、稳定再以版本形式进入 main。分支目标与默认行为默认情况下By default分支目标target指向main但大多数贡献应指向 dev。这句话的含义是在 GitHub 上发起 Pull Request 时仓库默认的合并目标分支是 main但按照项目约定普通的功能开发和 bug 修复都应当把 PR 指向 dev而不是 main。这与多数主干开发型仓库的习惯相反是 yfinance 为了兼顾稳定性与迭代速度而做的刻意设计。允许直接合入 main 的例外情况文档明确列出了三类可以直接向 main 发起合并Direct merges to main的例外yfinance 大规模损坏yfinanceis massively broken——例如整个库无法导入、核心 API 全部失效需要紧急止血部分功能损坏且修复简单、隔离Part ofyfinanceis broken, and the fix is simple and isolated——修复只影响单一模块、风险可控无需经过 dev 的长时间集成测试不改动代码的变更Not updating the code, e.g. docs——纯文档docs更新不会影响运行时行为可以直接合入 main。从仓库的实际 CI/CD 配置可以进一步印证分支与发布流程的对应关系见下文与分支模型对应的工程流水线一节main 是唯一被自动化流程监听的分支。二、创建你的开发分支Fork → Clone → Branch → Commit → Push → PR文档给出的完整流程如下共六个步骤。其中第 1 步在 GitHub 网页端完成其余为本地 Git 操作。1. Fork 仓库并同步在 GitHub 上 Fork yfinance 仓库。如果之前已经 Fork 过记得先点击Sync fork同步确保你的 Fork 与上游一致避免基于过期的代码开发。2. 克隆你的 Forkgit clone https://github.com/{user}/{repo}.git其中{user}是你的 GitHub 用户名{repo}是你的 Fork 仓库名。3. 从合适的基分支创建新分支git checkout {base e.g. dev} git pull git checkout -b {your branch}关键点在于基分支base branch的选择根据上文的分支模型功能开发和常规 bug 修复应以dev为基只有文档更新或紧急修复才考虑以main为基。先git checkout到基分支并git pull拉取最新再git checkout -b从它派生出你自己的工作分支这样后续的 PR diff 会最小、最干净。4. 提交变更并推送git commit -m short sentence summary -m full commit message # Long message can be multiple lines (tip: copy-paste)为了让提交历史和 GitHub 的network graph网络图保持紧凑提交信息被要求采用一句简短摘要 完整说明的双段式结构第一条-m是短句摘要short sentence summary第二条-m是完整提交信息full commit message可以多行、可以直接粘贴较长说明。这种写法既让git log --oneline一目了然又保留了完整的上下文避免长标题挤爆网络图。5. 发起 Pull Request在 GitHub 上Open a pull request将你的 Fork 分支合并到上游仓库。PR 的合并目标base按第一部分的分支模型选择默认是 main但大多数贡献应指向 dev。如果是修复某个 Issue建议在 PR 描述中关联该 Issue 编号见 CONTRIBUTING.md 的建议。说明原文档编号跳过了 5直接在步骤 4 之后标注了 6。本文按实际操作顺序重新编号为 1–5内容与原文完全一致。三、运行一个分支本地安装与验证贡献代码前通常需要在本地跑通目标分支。文档将这一部分指引到专门的运行指南页面原文档中的链接.../development/running.html对应当前仓库的 doc/source/development/running.rst这里综合两处内容给出完整方案。方式一直接用 pip 安装某分支pip install githttps://github.com/{user}/{repo}.git{branch}例如安装某个 feature 分支pip install githttps://github.com/ranaroussi/yfinance.gitfeature/name这种方式的优点是一行命令、即装即用适合快速试用别人的分支缺点是无法直接修改源码。方式二克隆源码并以可编辑模式安装推荐用于开发git clone https://github.com/ranaroussi/yfinance.git cd yfinance pip install -e .[dev]如果要安装特定分支git clone -b {branch} https://github.com/ranaroussi/yfinance.git cd yfinance pip install -e .[dev]其中-e是可编辑安装editable install源码改动即时生效.[dev]会一并安装开发依赖。这些开发依赖定义在 pyproject.toml 的[project.optional-dependencies] dev段包含pytest9.0.3与pytest-cov7.1.0——单元测试与覆盖率ruff0.15.16——Python 代码静态检查lintersphinx8.0.2、pydata-sphinx-theme0.15.4、sphinx-copybutton0.5.2、jinja23.1.4——Sphinx 文档构建工具链。让 Python 找到你的本地源码仅全局安装时需要文档特别加了一个 NOTE只有当你准备全局安装而非针对单个项目时才需要执行这一步如果是在某个项目目录里使用可以跳过直接在项目目录git clone即可。两种做法任选其一把下载目录加入PYTHONPATH环境变量在 Python 文件顶部插入路径import sys sys.path.insert(0, path/to/downloaded/yfinance)验证安装import yfinance print(yfinance)输出应当指向你下载的源码目录module yfinance from path/to/downloaded/yfinance/yfinance/__init__.py如果输出变成了site-packages下的路径如module yfinance from .../lib/python3.10/site-packages/yfinance/__init__.py说明第 2 步路径设置没有生效Python 导入的是已安装的发布版而不是你的本地分支。四、Git 实战技巧rebase、squash 与 force-with-lease这是 doc/source/development/code.rst 的 Git stuff 小节也是被 CONTRIBUTING.md 单独摘录为 Git tricks 的重点内容目的是保持提交历史和 network graph 紧凑、避免未来合并冲突。技巧一把分支从 main 基底迁移到 devrebase --onto在评审 PR 时维护者可能会要求把你的分支从main基底迁移到dev因为按分支模型大多数 PR 应以 dev 为目标。文档给出的完整命令序列是# 1) 先更新所有涉及的分支 git checkout main git pull git checkout dev git pull # 2) 把 {your branch} 从 main 基底重放到 dev 之上 git checkout {your branch} git pull git rebase --onto dev main {your branch} git push --force-with-lease origin {your branch}git rebase --onto dev main {your branch}的含义是把{your branch}中从main分叉出来的所有提交全部剪切并重放到dev的最新提交之上。它不会产生 merge 提交历史保持线性。注意必须更新所有涉及的分支main、dev、你的分支否则基底不完整会导致 rebase 失败或结果错误。技巧二用 rebase 而不是 merge 来同步基分支的新提交git checkout {base branch e.g. dev} git pull git checkout {your branch} git rebase {base} git push --force-with-lease origin {your branch}git rebase可以把你分支上没有的新基分支提交接到你的分支上而不会像git merge那样在你的分支历史里额外增加一个合并提交。文档明确解释了这样做的收益让历史保持干净keeps history clean、避免未来的合并问题avoids future merge problems。技巧三用 interactive rebase 做 squash 合并提交对于微小的、可以忽略的提交tiny or negligible commits应当用 squash 把它们与有意义的提交合并对于一连串连续的同类提交也应当合并成一个。这是保持 PR 可读性的关键。git rebase -i HEAD~2 git push --force-with-lease origin {your branch}git rebase -i HEAD~2会打开交互式编辑器列出最近 2 个提交把后面一个的pick改为squash或s即可合并进前一个。操作完成后同样用git push --force-with-lease推送。为什么始终使用 --force-with-lease 而不是 --force文档在以上所有需要改写历史的场景中都统一使用git push --force-with-lease origin {your branch}--force-with-lease只在你本地所知的远端状态与远端实际状态一致时才允许强制推送如果有人在你上次 fetch 之后又推送了新提交它就会拒绝推送并报错。这比裸--force安全得多能避免覆盖协作伙伴的提交。五、与分支模型对应的工程流水线CI/CD 印证yfinance 的自动化流水线配置在 .github/workflows 目录下它们恰好验证了 main 稳定 发布 这一分支模型定位python-publish.yml监听 GitHubrelease 事件release: types: [created]自动python -m build构建 wheel/sdist 并用 twine 上传到 PyPI。这与文档中main 是产生 PIP 发布的分支完全对应——release 是从 main 打 tag 的deploy_doc.yml监听对main 分支的 pushbranches: [main]自动执行pip install -e .[dev]与sphinx-build -b html doc/source doc/_build/html -v再把生成的 HTML 部署到documentation分支。这与 doc/source/development/documentation.rst 中合入 main 触发文档自动构建的描述一致——所以纯文档变更被允许直接合入 main正是为了尽快触发文档站点更新ruff.yml与pyright.yml对代码做静态检查。其中 ruff 的规则集在 ruff.toml 中固定为E4/E7/E9/F并排除自动生成的yfinance/pricing_pb2.py以保证 CI 结果跨 ruff 版本确定pytest.yml.disabled测试工作流当前处于禁用状态与 doc/source/development/testing.rst 中现有测试已有一定数量失败/错误的现状相符这也正是文档强调大多数贡献应先合入 dev 集体测试、冲突解决后再进 main的实践背景。因此本文第一部分的分支模型不只是纸面约定它直接决定了仓库的文档发布、PyPI 发布与代码质量检查三条自动化流水线的触发条件。六、合入前的工程检查测试与代码规范在向 dev 提交 PR 之前建议在本地完成两项工程检查详见 doc/source/development/testing.rst运行单元测试yfinance 的测试写在tests/目录下如 tests/test_prices.py、tests/test_ticker.py 等二十余个测试文件另有tests/data/存放行情修复测试的 CSV 数据。安装开发依赖后# 运行全部测试 pytest # 运行单个文件 pytest tests/test_prices.py # 运行指定测试类::方法 pytest tests/test_prices.py::TestPriceRepair::test_ticker_missing注意原文档特别提示当前仓库中的测试已存在一定数量的失败/错误Failures: 11、Errors: 93、Skipped: 1 左右这一现状正在持续改善中如果你的改动恰好命中了失败项请留意是否是既有问题而非你的回归。静态检查运行ruff配置见 ruff.toml确保新增代码不引入 E4/E7/E9/F 类问题若涉及类型标注也可参考 pyproject.toml 中[tool.pyright]的 basic 模式配置自查。七、小结贡献 yfinance 的黄金流程综合 doc/source/development/code.rst 及其关联页面向 yfinance 贡献代码的完整路径是选对分支常规功能与 bug 修复 → 基分支选dev紧急修复 / 大规模故障 / 纯文档 → 才考虑直接面向main走对流程Fork → Sync fork → Clone →git checkout -b→ 双段式 commit message → push → Open PR目标分支按模型选择本地验证用pip install git...{branch}或git clone -b {branch}pip install -e .[dev]跑通分支确认import yfinance指向本地源码保持历史整洁用git rebase --onto dev main {your branch}迁移基底、用git rebase {base}同步更新、用git rebase -i HEAD~2做 squash统一以git push --force-with-lease origin {your branch}推送改写后的历史通过工程检查运行 pytest 与 ruff必要时按 doc/source/development/documentation.rst 更新对应文档Sphinx 构建命令为sphinx-build -b html doc/source doc/_build/html可配合python -m http.server -d ./doc/_build/html本地预览。遵循这套规范你的贡献既能快速进入 dev 集体测试也不会给 main 的稳定发布带来风险——这正是 yfinance 双层分支模型要达成的最终目标。【免费下载链接】yfinanceDownload market data from Yahoo! Finances API项目地址: https://gitcode.com/GitHub_Trending/yf/yfinance创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考