PyCryptoBot / 版本与分支现状
你 clone 到的是哪一年的代码？三轨道对照
README 给出的升级方式只有两行：git checkout main 然后 git pull。所以真正决定你手上代码新旧的不是 Release 页面，而是 main 分支上最后一个提交是哪一天。
把三个时间点并排看，结论就很清楚：main 分支最后提交是 1fa9aaef（2024-03-04）；最新发行版 8.2.4 也是 2024-03-04；而 beta 分支上有一条 f5319e42（2025-05-26）的钱包修复，比 main 新 14 个月，至今没有合并进主线。同一份仓库里还有一个更容易看错的信号：仓库的活动时间戳显示 2026-03-26，但它来自其它分支，不代表 main 有更新。
这一页不替官方下任何结论，只把可核对的时间点、分支清单与自查命令列出来，让你确认自己拿到的到底是哪一版。
- PyCryptoBot v8.2.4（main=1fa9aaef，2024-03-04）
- Python 3.11（官方 Dockerfile 基线）
- 交易所范围：Binance / Coinbase / KuCoin
- 验证日期 2026-09-21
- 本站未实机运行机器人
三个时间点为什么会容易被混成一个？
下面把「主线代码、发行版本、以及那条没被合并的修复」分开列。每一行都给出依据，你可以逐条复核。
| 观测对象 | commit / 版本 | 日期 | 它意味着什么 | 注意点 |
|---|---|---|---|---|
main 分支最后提交 | 1fa9aaef（Merge PR #841） | 2024-03-04 | README 让你取的就是这一版，它是「你能拿到的官方主线代码」 | 后续所有分支都从它岔出去，主线本身没有再前进 |
| 最新发行版 | 8.2.4 | 2024-03-04 | 与 main 同日，没有比它更新的正式发行 | Release 不等于「有更新的代码」，它只是给主线打了个标签 |
| Tag 列表（最新 5 个） | 8.2.4 / 8.2.3 / 8.2.2 / 8.2.1 / 8.2.0 | 8.2.0 可追溯到 2023 年 | 8.2.x 这一系列就是当前最新的一条版本线 | Tag 数量有限，不要用「Tag 很少」推断项目年龄 |
beta 分支最后提交 | f5319e42（fix: retrieve all the wallets in the account (#842)） | 2025-05-26 | 比 main 新 14 个月，内容是「取回账户内全部钱包」的修复 | 未合并；并且它是 beta，未经发行验证 |
CHANGELOG.md 最后一条 | [8.2.0] - 2023-04 | 2023-04 | 变更日志本身停在 8.2.0 | 8.2.1–8.2.4 有 Release，但日志没补条目——别用 CHANGELOG 判断最新版本 |
仓库 pushed_at | 2026-03-26 | 2026-03-26 | 仓库层面最近还有推送动作 | 该时间戳来自其它分支的活动，不代表 main 有提交；只看它会得出错误结论 |
| 仓库创建时间 | — | 2020-12-07 | 项目已有约 6 年历史，不是试验品 | 项目年龄长不等于代码随时代更新 |
| PyPI 上的包 | 四个候选名全部 404 | 2026-09-21 探测 | 没有官方发行包，所以也没有「装最新版」这条路径 | 结论限定为 pycryptobot / pycryptobot-api / pycryptobotlib / py-crypto-bot 这 4 个名字不存在 |
README 里为什么只有两行命令？
仓库根目录的 README 很短。它给出的升级方式与依赖更新方式一共两行，但这两行都不包含「这条主线停在哪一天」这个信息。
| README 里写了什么 | 它没告诉你什么 | 对使用者的实际影响 | 怎么补 |
|---|---|---|---|
升级版本：git checkout main + git pull | 没有说 main 的最后一个提交是 2024-03-04 | 你会以为「pull 一下就是最新」，实际主线已经一年多没动 | pull 完立刻 git log -1 --format="%h %ad" 自己看一眼 |
升级依赖：python3 -m pip install -r requirements.txt -U | 没有说 requirements.txt 里有多个 2020–2021 年的钉死版本 | 加 -U 会去装那些旧版本，正是安装容易出问题的原因 | 先读一遍 requirements.txt，再决定是否用容器路线 |
| README 标题标明版本号 v8.2.4 | 没说这个版本号对应哪一天 | 看到版本号会以为「8.2.4 挺新的」 | 用 Release API 或 Tags 页面对照日期 |
| 指向 Telegram 群与 GitHub Discussions 作为支持渠道 | 没有本地中文文档，也没有版本对照表 | 遇到问题要跨语言检索，且信息散落在讨论区 | 先看本站的报错排查库，再去官方渠道 |
| 指向 Medium 上的安装、配置、实盘测试三篇文章 | 文章是外部链接，内容与仓库版本不同步 | 照文章操作可能与当前 main 的行为有差异 | 以仓库源码与 config.json.sample 为准，文章只当背景 |
| 聊天气泡里列了 5 条防骗提醒 | 没给「如何确认代码来源」的校验方式 | 容易从第三方打包渠道拿到被改过的版本 | 只用官方仓库与官方镜像，核对 commit hash |
18 个分支分别是什么角色
分支数量本身说明不了什么问题，但分支的类型分布能说明：哪些工作开过头却没合、哪些是长期维护的补丁线。
| 分支类别 | 分支名 | 角色 | 合并状态 | 注意点 |
|---|---|---|---|---|
| 主干 | main | README 指引的默认起点，最后提交 2024-03-04 | — | 用户实际拿到的就是它 |
| 领先分支 | beta | 承担未发布的修复，最后提交 2025-05-26 | 未合并进 main | 切过去前先记下 main 的 commit，方便回退 |
| 交易所适配分支 | coinbase/advanced_trade_api | Coinbase 新版交易接口的适配工作 | 未合并 | 与 v8.0.0「added Coinbase Advanced Trade exchange」的说明相互对应 |
| 交易所热修分支 | hotfix/coinbase | 针对 Coinbase 的紧急修复 | 未合并 | 说明该交易所的适配仍处在修补阶段 |
| 依赖升级分支 | dependabot/pip/requests-2.33.0 | 由机器人自动提交的依赖升级 PR | 未合并 | 意味着哪怕有可直接合并的安全/兼容升级，也没有进主干 |
| 作者补丁分支 | whittlem-patch-1 到 whittlem-patch-12（共 12 个） | 作者在网页端直接改文件产生的临时分支 | 多为临时性质 | 数量多不代表活跃度高，它们通常是流程产物 |
| 其它功能分支 | telegram-control-minor-fix | Telegram 控制相关的小修 | 未合并 | 与 Telegram 遥控有关的改动可能没体现到主线 |
main 时，上面这些分支里的修复你一个都拿不到。如果你遇到的问题恰好属于「钱包读取不全」「Coinbase 适配」「依赖版本冲突」这几类，那么主线代码里可能还没有对应修复。不同目标该取哪一版？
「该用 main 还是 beta」没有统一答案，取决于你要解决什么。下面按目标拆开，并给出每一行的风险。
| 你的目标 | 建议取哪一版 | 理由 | 风险与注意点 |
|---|---|---|---|
| 先跑通、看它怎么工作 | main（即 8.2.4） | 这是 README 指引的路径，也是绝大多数教程对应的版本 | 不要假设它会随教程更新；教程里的界面文案可能与你的不同 |
| 遇到「账户钱包读取不全」这类问题 | 需要评估 beta | beta 上那条 f5319e42 正是取回全部钱包的修复 | beta 未经发行验证，切过去可能出现其它回归；务必先备份配置 |
| 需要 Coinbase 新版交易接口 | 需要评估 coinbase/advanced_trade_api | 该分支就是为这件事开的 | 这是功能分支而非发布分支，完成度需自己判断 |
| 关心依赖安全与兼容性 | 主线当前无法满足 | 依赖升级 PR（如 requests-2.33.0）未合并 | 只能自己 fork 后手动升级，并承担自测成本 |
| 需要长期稳定运行、不接受行为漂移 | main + 锁定 commit | 记录 commit hash 比记录分支名可靠得多 | 分支会移动，commit 不会；部署脚本里写死 hash |
| 要提交自己的改动 | 从 main 拉工作分支 | 基于主线便于后续跟进 | 上游不动意味着你的改动不会有冲突，也意味着不会有人替你合并 |
| 只想拿行情数据做研究 | 不必部署本项目 | 只为读一个指标而维护一台常驻机器人并不划算 | 见实盘运维与安全 |
记录 commit，不要记录分支名
git checkout main 今天和半年后可能指向不同的代码。把 1fa9aaef 这样的短 hash 写进部署脚本与笔记里，是成本最低的可复现手段。
把「版本」写进你的问题描述
去官方讨论区提问时，先给出 commit hash、Python 版本与交易所。这三项决定了别人能不能复现你的问题，也决定了你能否判断某条回答是否适用于你这一版。
升级前先备份配置与日志
config.json 与交易记录是你自己的资产，仓库里没有它们。切分支或重建容器前先复制一份，这一步几乎不需要成本。
怎么用五步确认自己跑的是哪一版？
与其相信任何一篇文档（包括本站），不如在你自己的环境里跑一遍。下面五步都是只读操作，不会修改仓库或触发交易。
确认默认分支名
命令：
git remote show origin | grep "HEAD branch"，或直接在网页端看仓库首页的分支下拉框。
这一步做什么：确认默认分支是main而不是master。
预期输出：显示main。如果显示master，说明你参考的资料过时了，raw 链接也会 404。看主线停在哪一天
命令：
git log -1 --format="%h %ad %s" --date=short main。
这一步做什么：直接读出主线的最后一个提交与日期。
预期输出：形如1fa9aaef 2024-03-04 Merge pull request #841 …。日期与你 clone 的时间无关。对比 beta 领先了多少
命令：
git log -1 --format="%h %ad %s" --date=short beta，再用git log --oneline main..beta | wc -l数领先的提交数。
这一步做什么：量化「领先 14 个月」这件事，而不是只相信一句描述。
预期输出：第一条给出f5319e42 2025-05-26 …；第二条给出具体的提交条数。列出全部远程分支
命令：
git branch -r（或用gh api repos/whittlem/pycryptobot/branches --jq '.[].name'）。
这一步做什么：确认未合并分支确实存在，以及它们的命名规律。
预期输出：包含origin/main、origin/beta、origin/hotfix/coinbase以及若干whittlem-patch-*。核对发行版本与标签
命令：
git tag --sort=-v:refname | head -5与git describe --tags main。
这一步做什么：把「我手上的代码」映射到一个发行号上，便于对外描述。
预期输出：前五行为 8.2.4 / 8.2.3 / 8.2.2 / 8.2.1 / 8.2.0；describe应能给出与主线对应的标签。
1fa9aaef（main，2024-03-04），Python 3.x，交易所 X」。这行字在你三个月后排查问题时价值很高——它把「我用的哪一版」这个最常见的歧义一次性消掉了。关于版本与分支的高频问题
回答基于 2026-09-21 对 GitHub 分支、标签与提交接口的核对；本页只陈述事实，不推测官方计划。
PyCryptoBot 是不是停止维护了？
本站不做这个判断，只给可核对的时间线：仓库未归档，许可为 Apache-2.0，创建于 2020-12-07；main 分支最后提交 1fa9aaef 在 2024-03-04，最新发行版 8.2.4 也是同一天；beta 分支有一条 2025-05-26 的提交，未合并。你可以据此自行判断。需要提醒的是「主线不动」和「不能用」是两件事——代码仍然可 clone、镜像仍然可拉，能不能用取决于你的交易所与依赖环境。
为什么仓库显示 2026 年有推送，但 main 却是 2024 年？
因为仓库层面的 pushed_at 记录的是任意分支的最近推送时间，不等同于默认分支的提交时间。本站实测到的 pushed_at 是 2026-03-26，而 main 的最后提交仍是 2024-03-04。这两件事可以同时成立。判断「主线有没有动」，唯一可靠的办法是看 main 的提交记录本身。
我该用 main 还是 beta？
默认从 main 开始，因为它是 README 指引的路径，也是绝大多数教程对应的版本。只有当你的具体问题（例如「账户里的钱包没被全部读到」）恰好对应 beta 上那条修复时，才值得评估切过去。切之前先记下 main 的 commit hash，方便回退；同时要接受 beta 未经发行验证这个前提。
Release 是 8.2.4，但 CHANGELOG 只写到 8.2.0，该信哪个？
两个都不完整，用途不同。Release 与 Tag 反映的是「打过标签的版本」，所以最新是 8.2.4；CHANGELOG.md 反映的是「作者手动整理的变更说明」，它最后一条停在 [8.2.0] - 2023-04，8.2.1 到 8.2.4 没有补条目。想知道某个版本改了什么，最可靠的做法是看该 tag 与前一版之间的提交记录，而不是只看日志文件。
没有 PyPI 包，会带来什么实际差别？
差别在三个地方。第一，没有 pip install 这条路径，只能 git clone 或跑容器；第二，没有「装某个版本号」的能力，你只能用「某个 commit 或 tag」来描述自己用的代码；第三，依赖管理完全交给你，requirements.txt 里钉死了多个 2020–2021 年的版本，加 -U 升级时会去装这些旧版本。本站探测的是 pycryptobot、pycryptobot-api、pycryptobotlib、py-crypto-bot 四个名字，全部 404。
本站的结论会过期吗？
会。所有涉及时间与版本的内容都对应 2026-09-21 这个采集日期，页首的「本文验证环境」块里也标了。如果你在很久之后读到这里，请先回到 GitHub 仓库看 main 的最新提交与 Release 列表，再判断哪些结论仍然成立。本站不提供自动更新，也不保证与未来版本一致。