32、开源项目的打包、发布与人员管理

开源项目的打包、发布与人员管理

1. 提交的逻辑性

在软件开发中，提交代码的方式会对项目产生重要影响。例如，当有人需要将 BuildDir 错误检查修复移植到即将发布的维护版本分支时，问题就会凸显出来。假设一次提交包含了多个不相关的更改，如修复 ticket #1729、修改 BuildDir 中的过时注释和代码格式、修复 BuildDir 错误检查以及调整 index.html 文件。但在维护版本分支中，可能只有 BuildDir 错误检查修复是需要的，其他更改并不适用。然而，由于版本控制系统将这些不相关的更改逻辑分组，很难通过版本控制工具的合并功能仅提取 BuildDir 的更改。

实际上，这次提交应该拆分为四个独立的提交：
- 修复 issue #1729
- 移除 BuildDir 中的过时注释并重新格式化代码
- 修复 BuildDir 中的错误检查
- 调整 index.html

每个提交只包含一个逻辑更改有诸多好处。从心理层面讲，语义统一的提交更易于审查，必要时也更容易回滚。开发人员在提交时多一些前期的规范，能为项目后期避免很多麻烦。

2. 发布计划

开源项目和专有项目在发布计划上存在差异。专有项目通常有更明确的截止日期，这可能是因为向客户承诺了升级的时间、为了营销需要与其他工作协调，或者是为了满足风险投资家看到成果后继续投资的要求。而自由软件项目更关注在众多参与者（甚至可能是商业竞争对手）之间保持合作的工作氛围，维护工作关系有时会比单个方的截止日期更重要。

不过，很多开源项目由企业资助，受注重截止日期的管理层管理。这可能会导致拿薪水的开发者和志愿者之间在发布时间