贡献说明

分支

gh-build：仅仅在发布版本时由 @ccmywish 推送，触发编译到 GitHub Releases 中
main: stable，代码一定是可以编译运行的，我们假设 end users 在其他条件都得不到二进制时，会自己编译这个分支来运行 chsrc
dev：开发分支，工作分支，在此分支上解决冲突

第一次贡献者

注册身份信息

在 src/chsrc-main.c 的 chsrc_register_contributors() 函数里，在最后（我们按参与本项目的时间顺序排列）添加一行：

chef_register_contributor ("@ID: 你的GitHub/Gitee用户名或任意不与其他贡献者冲突的名字",
  "你的真实姓名",
  "你的邮箱地址",
  "若 chsrc ls <recipe> 的时候不想使用真实姓名，可以用这个参数的字符串来代替");

更新 Recipe 信息

在你修改的 recipe 文件的 _prelude() 函数里，需要做以下更新：

更新 recipe 修改时间（每次修改 recipe 代码都要更新）：
c
```
chef_set_recipe_last_updated (this, "YYYY-MM-DD");
```
更新镜像源信息时间（仅当你修改了镜像源列表时才更新）：
c
```
chef_set_sources_last_updated (this, "YYYY-MM-DD");
```

将自己加入 sauciers（次要贡献者列表，将计数加一并添加自己的 @ID）：

// 原来是 0 个 saucier：
chef_set_sauciers (this, 0);
// 改为添加你自己：
chef_set_sauciers (this, 1, "@你刚注册的ID");

// 原来已有 1 个 saucier：
chef_set_sauciers (this, 1, "@Someone");
// 改为添加你自己：
chef_set_sauciers (this, 2, "@Someone", "@你刚注册的ID");

验证上述信息正确

# 应当能看到你的信息
./chsrc ls <recipe>

提交与审阅

当你提交 PR 的时候，一定要将 PR 指定 chsrc 原仓库的 dev 分支。

一个简单的 Bug

一个简单的 Bug fix，有写权限的维护者可以直接推送到主仓库的 dev 分支

不太容易修复的 Bug 以及新功能

这里要分两种情况考虑。（1）recipe 相关的（2）framework 相关的

（1）

如果你是 recipe Chef，则你完全负责这个 recipe，如果你拥有写权限，你可以直接推送代码到 dev 分支

（2）

需要先搜索你修改的部分涉及到的 recipe，然后提 issue @ 所有相关的 recipe Chef 来 review
如果涉及了所有 recipe，则 @ framework Chef，而无需把所有 recipe 的 Chef 都喊过来，但是如果觉得有必要，可以 @ 任意你觉得有能力 review 和能给出建议的人来 review

最好总是 issue 或 PR

对于有写权限的维护者来说，即使是能够直接推代码，最好也都先提 issue 或 PR，因为这样能够让大家知道代码发生了哪些变动。

如果你觉得要和大家讨论，则 issue；如果你觉得没有讨论的必要了，则直接 PR 后自己立即合并即可。之所以多此一举，是因为这能够显式地记录代码的加入过程，其相当于一份文档方便未来的自己和他人查阅