������������ | Python 项目管理

点击蓝字关注我们

Python 项目管理：Mesa 开源开发特训营核心笔记（2026年第4期）

导读

在开源项目的演进过程中，“写出能运行的代码”只是第一步，“让项目可持续地被理解、贡献和维护”才是真正的分水岭。当团队规模扩大、协作变得频繁，没有统一规范的项目管理往往会陷入代码冲突频发、环境不一致、新成员难以上手等困境。

ABMind 社区 Mesa 特训营第四期系统梳理了 Python 开源项目管理的完整框架：从测试、文档、CI/CD、代码质量工具、依赖管理五大核心要素，到标准化的项目结构、版本控制策略与发布流程——本期笔记带你全面掌握如何构建一个高质量、可维护、可协作的开源项目。无论你是正在启动新项目的创作者，还是希望为现有项目建立规范的管理者，这期都将帮助你从“能用”走向“好用”，让项目真正具备长期生命力。

---

ABMind 第四期

主讲人 | 宋爽

（个人模板仓库：https://github.com/SongshGeo/Python-Project-Template）

整    理 | 胡瀚云

为什么需要项目管理

协作的核心需求

在团队协作开发的过程中，我们常常会遇到一系列典型的问题，这些问题如果没有合理的机制来解决，就会严重影响团队的开发效率。当多人同时对同一个项目进行修改时，我们需要思考如何有效避免代码之间的冲突，同时还要确保团队中的每一位成员都能够使用统一的代码风格和工具版本，避免因为个人习惯的差异导致代码难以维护，除此之外，我们还需要考虑如何让新加入团队的成员能够快速理解项目的整体结构，从而快速上手参与到项目的开发中来，而不是花费大量的时间去摸索项目的情况。

针对这些协作过程中遇到的问题，我们可以通过一系列成熟的工具和流程来逐一解决。首先，我们可以使用 Git 这一版本控制工具来管理代码的变更历史，通过它我们可以清晰地追踪每一次代码修改的内容和作者，从而在合并代码的时候能够更高效地处理可能出现的冲突。其次，我们需要做好项目的依赖管理，通过pyproject\.toml或者requirements.txt这样的配置文件来锁定项目所需要的依赖版本，确保不同的开发环境都能够使用完全一致的依赖，避免因为依赖版本的差异导致项目无法运行。最后，我们还需要统一团队的代码规范，我们可以使用 Black、Ruff 这样的工具来自动格式化代码，让所有的代码都能够保持一致的风格，同时我们还可以通过 pre\-commit hooks 来在代码提交之前自动完成这些检查，确保所有提交到仓库的代码都符合团队的规范。

这些措施的落地能够为团队带来非常显著的实际收益，它不仅能够有效减少代码合并时的冲突，大幅提升团队整体的协作效率，还能够彻底解决过去常常出现的 “在我机器上能跑” 的尴尬问题，让项目在不同的环境中都能够稳定运行，同时，标准化的项目结构和工具流程也能够有效降低新成员的学习成本，让他们能够更快地熟悉项目，融入到团队的开发工作中来。

标准化的必要性

在没有统一标准的开发环境中，我们常常会遇到不少阻碍开发效率的问题。不同的项目往往会使用完全不同的项目结构，这就导致开发人员在切换项目的时候，需要花费大量的时间去重新熟悉项目的文件布局，难以快速定位到自己需要的代码。同时，不同项目之间也缺少统一的配置管理方式，每个项目都有自己的一套配置逻辑，这也增加了开发人员的学习和维护成本。除此之外，代码的风格也会因为开发者的个人习惯而千差万别，不同的人写出来的代码格式和风格都不一样，这就导致代码的维护成本变得非常高，尤其是当项目的规模变大，参与的人数变多之后，这个问题会变得越来越严重。

为了解决这些问题，我们需要在团队和项目中推行标准化的开发流程和规范。首先，我们需要统一项目的结构，遵循 Python 项目的最佳实践，比如采用 src-layout 这样的标准项目结构，让所有的项目都能够保持一致的文件布局，这样开发人员在切换项目的时候，就能够快速找到对应的文件。其次，我们需要统一配置文件的管理方式，使用pyproject.toml这一现代的配置文件来统一管理项目的元数据、依赖信息以及各种工具的配置，让所有的配置都能够集中在一个文件中，方便管理和维护。最后，我们还需要统一团队的代码风格，使用统一的格式化工具和 lint 规则，让所有的代码都能够保持一致的风格，不管是谁写的代码，看起来都是统一的，这样就能够大幅降低代码的维护成本。

这些标准化的措施能够带来非常多的好处，它能够有效提高代码的可读性和可维护性，让代码更容易被理解和修改，同时也能够降低开发人员在不同项目之间的切换成本，让他们能够更快地适应不同的项目。除此之外，统一的标准也能够更方便地集成各种自动化工具，让我们能够更高效地使用各种工具来提升开发效率和代码质量。

保障代码变更的安全性

在项目的开发过程中，我们不可避免地会不断修改代码，添加新的功能，但是在这个过程中，我们常常会担心自己的修改会不会破坏现有的功能，导致原本可以正常运行的代码出现问题。我们需要思考如何能够快速发现因为代码修改带来的回归问题，也就是新的改动导致旧的功能无法正常运行的情况，同时，我们也希望能够在不影响现有功能的前提下，安全地对代码进行重构，优化代码的结构和性能。

针对这些问题，我们可以通过一系列的质量保障机制来解决。首先，我们需要编写自动化测试，包括单元测试和集成测试，通过这些测试来验证代码的功能是否符合我们的预期，确保我们的代码变更不会破坏现有的功能。其次，我们可以引入持续集成也就是 CI 的机制，在每一次代码提交的时候，自动运行所有的测试，这样我们就能够及时发现代码修改带来的问题，而不是等到开发完成之后才发现。除此之外，我们还可以使用类型检查工具，通过在代码中添加类型提示，然后使用 mypy 这样的工具来静态地检查代码中的类型错误，提前发现一些潜在的问题，避免这些问题在运行的时候才暴露出来。

这些机制能够有效提升代码的质量和稳定性，减少生产环境中出现 bug 的概率，让项目能够更加稳定地运行。同时，完善的测试和检查机制也能够让我们在重构代码的时候更有信心，不用担心自己的重构会破坏现有的功能，从而能够更放心地对代码进行优化，提升代码的质量。

面向用户的友好性设计

当我们开发完成一个项目之后，最终是要交付给用户来使用的，但是在这个过程中，我们常常会忽略用户的使用体验。我们需要思考，用户要如何安装和使用我们的项目，有没有简单易懂的方式让用户能够快速上手，同时，我们还要考虑如何让用户能够快速了解项目的功能，知道这个项目能够帮他们解决什么问题。除此之外，当用户在使用项目的过程中遇到错误的时候，我们能不能提供清晰的错误信息，让用户能够知道问题出在哪里，以及如何解决这个问题，而不是给出一堆用户看不懂的错误栈。

为了提升用户的使用体验，我们需要在项目中做好用户友好的设计。首先，我们需要提供清晰完善的文档，包括项目的 README 文件、详细的 API 文档以及对应的使用教程，让用户能够通过这些文档快速了解项目的使用方法。其次，我们需要提供简单的安装流程，让用户可以通过pip install或者 uv 这样的工具一键完成项目的安装，不需要用户自己去处理复杂的依赖问题。除此之外，当用户在使用过程中遇到错误的时候，我们要提供友好的错误提示，给出有意义的错误信息，以及对应的解决建议，帮助用户快速解决问题。

这些用户友好的设计能够有效提高项目的可用性，让更多的用户愿意使用我们的项目，从而提升项目的采用率。同时，完善的文档和友好的错误提示也能够减少用户的支持成本，不需要我们花费大量的时间去回答用户的问题，帮助用户解决各种使用中的问题。除此之外，良好的用户体验也能够帮助我们建立项目的良好声誉，吸引更多的用户来使用我们的项目。

面向贡献者的友好性设计

对于开源项目来说，外部贡献者是项目能够持续发展的重要动力，但是我们常常会发现，很多外部贡献者想要为项目贡献代码的时候，却不知道该从何入手。我们需要思考，如何让这些外部贡献者能够快速理解项目的结构，知道项目的代码是如何组织的，同时，我们还要引导这些贡献者遵循项目的开发规范，让他们提交的代码能够符合项目的要求。除此之外，我们还要尽可能简化贡献的流程，让贡献者能够更轻松地为项目提交代码，而不是被复杂的流程挡住。

为了让贡献者能够更轻松地参与到项目的开发中来，我们需要做好面向贡献者的友好设计。首先，我们需要提供完善的贡献指南，也就是 CONTRIBUTING.md 文件，在这个文件中详细说明如何为项目提交代码，如何报告项目中的问题，以及项目的开发规范是什么。其次，我们需要提供清晰的开发环境配置说明，让贡献者能够按照说明快速搭建好项目的开发环境，不需要自己去摸索如何配置环境。最后，我们需要建立规范的代码审查流程，通过 Pull Request 的流程来接收贡献者的代码，并且在审查的过程中为贡献者提供反馈和改进的建议，帮助他们写出符合项目要求的代码。

这些措施能够有效吸引更多的贡献者参与到项目的开发中来，让项目能够获得更多的外部贡献，同时，规范的代码审查流程也能够有效提高代码的质量，确保提交的代码都能够符合项目的要求。除此之外，友好的贡献流程也能够帮助项目建立一个活跃的社区，让更多的人愿意参与到项目的开发和讨论中来，推动项目持续发展。

权限与职责的制度化管理

随着项目的发展，参与的人员会越来越多，不同的人员在项目中承担的角色也不一样，这时候我们就需要对权限和职责进行分级管理。我们需要思考，如何控制谁可以将代码合并到主分支，避免随意的合并破坏主分支的稳定性，同时，我们还要管理不同角色的权限，比如维护者、贡献者和用户，他们应该拥有不同的权限，能够执行不同的操作。除此之外，我们还要保护项目中的关键分支，比如主分支，避免因为误操作导致这些分支被破坏。

针对这些问题，我们可以通过平台的权限管理功能和分支保护规则来解决。首先，我们可以为主分支设置分支保护规则，要求所有合并到主分支的代码都必须经过代码审查，不能直接将代码推送到主分支。其次，我们可以使用 GitHub 或者 GitLab 这样的平台提供的权限系统，来管理不同角色的权限，区分维护者和贡献者的权限，让不同的角色能够执行符合自己职责的操作。最后，我们还可以设置自动化的检查，要求所有合并到主分支的代码都必须通过测试、lint 检查等自动化的质量检查，确保合并的代码都是符合质量要求的。

这些措施能够有效保护代码库的稳定性，避免因为误操作或者不合格的代码合并导致代码库被破坏，同时也能够确保合并到主分支的代码都能够符合项目的质量要求，保证代码的质量。除此之外，明确的权限和职责划分也能够让团队中的每一个人都清楚自己的责任，明确责任分工，让项目的管理更加清晰有序。

项目管理的核心要素

测试（Testing）

测试是确保代码质量的核心手段，它在项目的开发过程中扮演着至关重要的角色。通过测试，我们可以验证代码的功能是否符合我们的预期，确保代码能够按照我们设计的方式运行。同时，测试还能够有效防止回归问题的出现，也就是避免新的代码改动破坏了原本已经正常运行的旧功能，让我们的代码在不断迭代的过程中能够保持稳定。除此之外，测试本身也可以作为代码的文档，通过测试用例，其他的开发者可以清晰地了解这段代码应该如何使用，它的输入和输出是什么样的。最后，完善的测试也能够支持我们安全地对代码进行重构，让我们在修改代码结构的时候，不用担心会破坏现有的功能。

从测试的范围和层级来看，我们可以将测试分为不同的类型，来覆盖不同的测试场景。首先是单元测试，单元测试主要针对单个的函数或者类进行测试，它的目标是验证这个最小的代码单元的功能是否正常。单元测试的特点是快速、隔离并且可重复，我们可以通过 pytest 或者 Python 自带的 unittest 这样的工具来编写单元测试，这些工具能够帮助我们快速地运行测试，并且给出清晰的测试结果。其次是集成测试，集成测试主要测试多个组件之间的交互是否正常，验证系统的整体功能是否能够正常运行，因为很多时候，单个的组件单独测试是正常的，但是当它们组合在一起的时候，就可能会出现问题，这就需要集成测试来发现这些问题。最后是端到端测试，也就是 E2E 测试，这种测试会从用户的视角出发，测试完整的工作流程，模拟用户真实的使用场景，这种测试的覆盖面最广，但是对应的成本也最高，因为它需要运行整个系统的流程。

在编写测试的时候，我们也有一些最佳实践可以遵循。首先是测试覆盖率，我们建议将 80% 的测试覆盖率作为基本的目标，而对于核心的代码路径，比如核心算法、公共 API 以及数据读写这些关键的部分，我们应该争取达到接近 100% 的覆盖率，这样才能确保这些关键的部分都能够被测试覆盖到。其次，我们可以使用测试驱动开发也就是 TDD 的方式来开发代码，这种方式的逻辑是先编写测试用例，然后再编写代码的实现，不断调整代码直到测试通过，这种方式能够帮助我们写出更符合需求的代码，并且确保代码的功能都能够被测试覆盖。最后，我们的测试应该保持独立、可重复并且能够快速执行，这样我们才能够频繁地运行测试，及时发现问题。

常见的测试层级可以分为三类：

1. 单元测试（Unit tests）：只测一个函数/类，快速、隔离、可重复。工具可参考：pytest（常用测试框架）、unittest（Python 自带测试框架）。
2. 集成测试（Integration tests）：测试多个组件之间的交互是否正常，验证系统的整体功能可顺利运行。
3. 端到端测试（E2E tests）：从用户视角运行完整流程（例如安装→运行示例→生成结果），模拟真实场景，这种方法覆盖面最广但成本最高。

接下来是一个测试的示例，通过这个示例我们可以看到单元测试的编写方式：

文档（Documentation）

文档是项目与用户、贡献者之间沟通的桥梁，它承载着项目的说明、使用方法以及开发规范等重要信息，一个完善的文档体系是项目能够长期发展的重要保障。文档的组成部分有很多，其中最基础的就是 README.md 文件，它是用户打开项目仓库首先看到的内容，里面包含了项目的概览、快速开始的指引以及安装说明，能够帮助用户快速了解项目是什么，以及如何快速上手使用项目。除此之外，我们还需要详细的 API 文档，用来说明项目中的函数和类的详细使用方法，方便开发者调用项目的接口。同时，我们还需要提供对应的教程和示例，向用户展示项目的使用场景和最佳实践，帮助用户更好地使用项目。最后，对于开源项目来说，我们还需要贡献指南，用来指导外部的贡献者如何参与到项目的开发中来。

根据受众的不同，我们可以将文档分为不同的类型，来满足不同人群的需求。

• 首先是面向用户的用户文档，这类文档主要是为使用项目的用户准备的，它包含了项目的安装指南，告诉用户如何安装项目，还有使用教程，指导用户如何使用项目的各项功能，同时还有常见问题 FAQ，用来解答用户在使用过程中常见的一些问题，以及示例代码，让用户可以通过复制粘贴的方式快速运行项目的示例，了解项目的使用方法。
• 其次是面向开发者的开发者文档，这类文档主要是为参与项目开发的开发者准备的，它包含了项目的架构设计，说明项目的整体架构是如何设计的，各个模块之间是如何交互的，还有 API 参考文档，详细说明项目的 API 如何使用，同时还有开发环境的设置说明，指导开发者如何搭建项目的开发环境，以及贡献指南，告诉开发者如何为项目贡献代码。
• 最后是代码内的文档，这类文档是写在代码里面的，主要是为阅读代码的开发者准备的，它包括了函数和类的 docstring，用来说明这个函数或者类的功能、参数和返回值，还有行内的注释，需要注意的是，行内注释应该解释的是 “为什么” 要这样做，而不是代码 “是什么”，因为代码本身已经能够说明它是什么了，而注释需要解释的是背后的设计选择和原因。

在编写文档的时候，我们也有一些最佳实践可以遵循。首先，我们应该统一 docstring 的风格，比如使用 Google 或者 NumPy 风格的 docstring，这样不管是开发者还是文档生成工具，都能够稳定地解析这些文档。其次，我们需要保持文档与代码的同步更新，每一次代码的变更，比如 API 的修改、参数的变化，都需要同步更新对应的文档，否则文档就会很快过时，变成误导用户的内容。同时，我们需要提供可运行的示例代码，对于开源项目来说，能够让用户复制粘贴就跑通的示例，往往比写得很长的文档更加重要。最后，我们可以使用文档生成工具，比如 Sphinx、MkDocs 这些工具，来自动将我们的文档生成美观的站点，方便用户浏览。

接下来是一个代码文档的示例，通过这个示例我们可以看到 docstring 的编写方式：

持续集成 / 持续部署（CI/CD）

持续集成和持续部署也就是 CI/CD，它能够将测试、构建以及部署的流程全部自动化，通过这种自动化的流程，我们可以确保每一次的代码提交都能够经过自动化的检查，不需要人工去手动执行这些操作。这不仅能够帮助我们快速发现代码中的问题，并且及时修复这些问题，还能够有效减少人工操作带来的错误，同时也能够大幅提高项目的发布效率，让我们能够更频繁、更稳定地发布新版本。

CI/CD 的流程主要分为两个部分，首先是持续集成也就是 CI，这部分主要是针对代码提交后的自动化检查流程。当开发者提交了代码之后，就会自动触发自动化的测试，运行所有的测试用例，验证代码的功能是否正常。同时，还会自动运行 lint 检查，检查代码是否符合我们的规范，有没有代码质量的问题。除此之外，还会自动构建项目，验证项目是否能够正常构建，并且生成对应的测试报告，让我们能够清晰地看到测试的结果。通过这些自动化的检查，我们可以在代码提交的第一时间就发现问题，而不是等到开发完成之后才发现。

其次是持续部署也就是 CD，这部分主要是针对部署的自动化流程。当我们的代码推送到远端仓库之后，就会自动触发部署的流程，首先会自动将代码部署到测试环境，然后在测试环境中运行集成测试，验证系统在测试环境中是否能够正常运行。当测试通过之后，就可以自动将代码部署到生产环境，当然这一步是可选的，根据项目的需求来决定。通过这种自动化的部署流程，我们可以省去手动部署的繁琐步骤，减少人工操作的错误，让部署变得更加高效和稳定。

目前有很多常用的 CI/CD 工具可以选择，比如 GitHub Actions，它是 GitHub 集成的 CI/CD 平台，对于托管在 GitHub 上的项目来说非常方便，不需要额外的配置就可以使用。还有 GitLab CI，它是 GitLab 提供的 CI/CD 系统，和 GitLab 的集成也非常好。除此之外，还有 Jenkins，这是一个开源的自动化服务器，它的功能非常强大，可以支持各种复杂的自动化流程。

这是一个 GitHub Actions 的配置示例，通过这个示例我们可以看到如何配置一个自动化的测试流程：

代码质量工具

为了保障代码的质量，我们可以使用一系列的代码质量工具，来帮助我们自动检查代码中的问题，并且统一代码的风格。首先是代码检查也就是 Linting 工具，这类工具可以帮助我们检查代码中的问题，比如错误的语法、不符合规范的代码、潜在的 bug 等等。其中 Ruff 是一个非常快速的 Python linter，它可以替代过去的 Flake8、isort 等多个工具，一个工具就能够完成代码的检查和导入的排序，而且它的速度非常快，能够大幅提升我们的开发效率。除此之外，还有 Pylint，这是一个非常全面的代码质量检查工具，它可以检查代码中的各种问题，帮助我们提升代码的质量。另外，还有 mypy，这是一个静态类型检查工具，它可以检查我们代码中的类型标注和实际使用是否一致，提前发现类型相关的错误。

除了代码检查之外，我们还有代码格式化工具，这类工具可以自动将我们的代码格式化成统一的风格，不需要我们手动去调整代码的格式。其中 Black 是一个非常流行的代码格式化工具，它会按照统一的规则来格式化我们的代码，让所有的代码都能够保持一致的风格，而且它的配置非常少，几乎不需要我们去调整，就能够直接使用。另外，Ruff 也内置了格式化的功能，也就是 Ruff format，它的速度比 Black 还要快，能够快速完成代码的格式化。

为了让这些检查和格式化工具能够自动运行，我们可以使用 Pre\-commit Hooks，它可以在我们提交代码之前自动运行这些检查工具，只有当所有的检查都通过之后，才允许我们提交代码。这样就可以把这些质量检查的步骤前置到本地的提交阶段，避免我们把不符合规范的代码提交到仓库中，从而提升代码的质量和协作的稳定性。

这是一个 pre\-commit 的配置示例，通过这个示例我们可以看到如何配置这些自动检查的钩子：

依赖管理

依赖管理是项目管理中非常重要的一部分，它的目标是确保项目在不同的环境中都能够使用相同的依赖版本，避免因为依赖版本的差异导致项目无法运行，同时也能够避免依赖之间的冲突，并且简化项目的安装流程，让用户能够更轻松地安装项目的依赖。

目前有两种主流的依赖管理方式，首先是现代的方式，也就是使用 pyproject.toml 配合 uv 或者 pip 来管理依赖，这是现代 Python 项目的标准方式。通过 pyproject.toml，我们可以统一管理项目的元数据和依赖信息，将所有的配置都集中在一个文件中，非常方便管理。而 uv 是一个非常快速的依赖管理工具，它的依赖解析和安装的速度都非常快，能够大幅提升我们安装依赖的效率。这种方式是目前推荐的方式，适合大多数的项目。

其次是传统的方式，也就是使用 requirements.txt 文件，这种方式非常简单直接，我们只需要在这个文件中列出项目的依赖和对应的版本就可以了，它非常适合小型的项目，因为小型项目的依赖比较少，使用这种简单的方式就足够了。不过现在很多现代的工具都支持导出 requirements.txt 文件，所以很多项目会让这两种方式共存，来兼容不同的用户和流程。

在实际的项目中，我们通常会把开发依赖和运行依赖分开，这样用户在安装项目的时候，只需要安装运行依赖就可以了，不需要安装开发依赖，从而让安装变得更加轻量，而开发者则可以通过额外的参数来安装完整的开发依赖，拉齐整个工具链。

这是一个 pyproject\.toml 的示例，通过这个示例我们可以看到如何配置项目的依赖和工具：

项目管理的最佳实践

标准化的项目结构

一个清晰的项目结构能够帮助我们更好地组织项目的代码和文件，让项目的结构更加清晰，方便开发者理解和维护。我们推荐使用如下的标准项目结构，这也是 Python 项目的最佳实践：

在这个结构中，我们使用了 src\-layout 的布局，也就是将所有的源代码都放在 src 目录下面，这是目前推荐的项目布局方式。之所以推荐这种布局，是因为它能够避免很多问题。首先，它可以防止我们误导入本地的开发代码，避免因为当前目录的路径优先级，导致我们在本地开发的时候导入的是源码目录的代码，而当我们把项目安装成包之后，却导入了错误的内容，从而出现 “本地能跑，装成包就坏” 的情况。其次，它能够强制我们测试安装后的包，而不是直接测试源码目录，这样我们的测试就能够更贴近真实用户的安装和使用方式，确保用户安装之后项目能够正常运行。除此之外，这种布局也能够让项目的组织更加清晰，生产代码、测试代码、文档以及 CI 配置都各归其位，能够有效降低团队的协作成本，而且这也是行业内的常见结构，符合开源和团队协作的惯例，维护者能够更容易接手项目。

版本控制的最佳实践

版本控制是团队协作开发的基础，我们需要遵循一些最佳实践，来让版本控制的流程更加规范和高效。首先是分支策略，我们需要对不同的分支进行明确的分工，来区分不同的开发阶段。其中 main 分支是生产环境的代码，这个分支的代码应该保持最稳定的状态，用户通常下载的就是这个分支的代码，所以这个分支的提交应该保持干净，每一次发布都对应一个版本号。然后是 develop 分支，这是开发的集成分支，开发者之间的协作主要发生在这个分支上，因为多人会频繁地合并代码到这个分支，所以这个分支的改动会比较密集，当这个分支上积累了足够的新功能之后，我们就会把它合并回 main 分支，并且发布新的版本。除此之外，我们还有 feature 分支，也就是功能分支，当我们要开发一个新功能的时候，我们会从 develop 分支拉出一个 feature/* 的分支，在这个分支上进行新功能的开发，当功能开发完成之后，再合并回 develop 分支，而不是直接合并到 main 分支。另外还有 fix 分支，也就是修复分支，用来修复项目中的 bug，当我们需要修复用户反馈的紧急 bug 的时候，我们会拉出 hotfix 分支，这个分支通常是除了 develop 分支之外，唯一需要直接和 main 分支交互的分支，因为它的目标是快速修复问题并且发布新版本。

其次是提交信息的规范，我们需要使用清晰的提交信息，来描述每一次提交做了什么修改，这样我们在查看提交历史的时候，就能够清晰地了解每一次修改的内容。我们推荐遵循约定式提交也就是 Conventional Commits 的规范，这种规范定义了提交信息的格式，比如feat: add color attribute to MoneyAgent，其中 feat 表示这是一个新的功能，通过这种标准化的提交信息，我们可以很方便地生成变更日志，并且自动管理版本号。

最后是代码审查，我们要求所有的代码变更都要通过 Pull Request 的方式来合并，不能直接推送到主分支，而且所有的 Pull Request 都需要至少一个人审查之后才能合并，通过代码审查，我们可以发现代码中的问题，确保代码的质量。同时，我们还会通过自动化的检查来确保代码的质量，比如测试、lint 检查等等，只有这些检查都通过了，才能合并代码。

典型的开发工作流

在遵循了上述的分支策略和规范之后，我们就有了一套标准的开发工作流，一个典型的开发流程是这样的：首先，我们会把项目的仓库克隆到本地，然后阅读仓库的 [README.md](README.md) 和 [CONTRIBUTING.md](CONTRIBUTING.md) 文件，了解项目的开发环境、代码风格、测试命令以及 PR 的规范，确保我们了解项目的开发要求。

接下来，我们会创建一个个人的功能分支，通过git checkout -b feature/add-color-attribute这样的命令，从 develop 分支拉出一个属于我们自己的功能分支，在这个分支上进行我们的代码改动。在开发的过程中，我们会编写对应的代码，同时编写对应的测试用例，来验证我们的代码功能是否正常，并且在开发完成之后，运行所有的测试，确保本地的测试都能够通过，没有问题。