前言

美国新一代天气预报系统UFS基于社区开发理念构建。从前文介绍的UFS软件栈可以看出，UFS非常复杂，由多个分量组件构成，其中一些分量模式由不同的组织开发团队主导开发维护工作。

UFS系统集成了多个分量组件，涉及多个团队开发，因此其协作开发流程相比单一团队开发要复杂一些。

基于Git/Github Fork工作流

UFS使用Git/Github管理代码开发。UFS主仓库维护一个主分支develop，分支HEAD记录反映了最新的提交更改。由于不同分量组件由不同团队主导，各自有自己的Git仓库。因此，UFS通过Git Submodule管理各个分量组件。

UFS仓库所有开发必须有一个相应的Github Issue。这使得代码管理员和社区能够讨论提议的开发的重要性和时间表。可以使用单个拉取请求 (PR) 修复多个issues，这就是为什么每个PR必须与至少一个issue联系。

因为UFS面向社区开发，因此Git Fork工作流最合适。

# 1. fork UFS仓库到自己的Github账号下
# 2. 克隆到本地机器
git clone https://github.com/<your_github_username>/ufs-weather-model
cd ufs-weather-model
# 3. 拉取分量submodule文件
git checkout develop
git submodule update --init --recursive
# 4. 创建特性(feature/)分支进行开发，使用`bugfix/`创建修正分支
git checkout -b feature/newfeaturename
# 5. 编辑文件、修改提交到Git版本中
git add filename; git commit -m "message"

如果针对分量进行开发，必须fork分量组件到个人账户并进行以上类似方式提交。

需要注意的是，在UFS主仓库中必须同时引入你对分量的更改

引入更改

如果还未克隆fork仓库到本地

• 进入你个人fork仓库，编辑.gitmodules文件

以对fv3atm进行更改为例，替换submodule url及branch内容为你个人仓库对应的。

[submodule "FV3"]
path = FV3
#url = https://github.com/NOAA-EMC/fv3atm
#branch = develop
url = https://github.com/<your_github_username>/fv3atm
branch = <your branch name>

• 然后和前面介绍的clone/checkout/submodule update操作一样。

如果已经在本地使用克隆和submodule update操作

• 在本地修改.gitmodules文件，修改内容与上面情况相同
• 进入分量目录cd FV3
• 更新远程仓库信息，即origin指向你个人fv3atm仓库

git remote rename origin upstream
git remote add origin https://github.com/<your_github_username>/fv3atm

• 检出个人开发分支

git fetch origin
git checkout origin/<your_branch_name>

回归测试（Regression Testing）

回归测试非常有必要，确保通过PR提出的更改不会以负面方式改变模式的构建或操作的方法。开发工作完成后，开发者需要将其功能分支与官方仓库中最新的开发/主分支同步并运行回归测试。

cd tests
./rt.sh -e -a <account> 

推送代码并发起PR

完成所有提交并通过所有回归测试（如果适用）后，您需要将这些更改推送到您创建的分支内的 GitHub 上的分支。

• 设置远程仓库信息

# 1. 确保已设置origin和upstream仓库信息
git remote -v
# 2. 如果没有设置`upstream`仓库，必须加入官方仓库为upstream仓库
#    upstream可用于同步官方仓库最新develop/master分支
git remote add upstream https://github.com/ufs-community/ufs-weather-model

• 推送更改记录

# 推送到个人仓库
git push origin feature/newfeaturename

强制要求（mandatory）

• 必须创建issue，将由对应PR解决
• PR所有讨论交流必须在Github上进行
• 开发者的特性分支必须与官方仓库相应分支保持同步并解决所有冲突
• 回归测试需要在所有支持平台通过（如开发者无权访问对应平台，在PR注明由管理员执行）
• 最后是鼓励开发人员为添加的任何功能创建新的回归测试，除了运行回归测试外使用utest测试可重复性

创建PR

对PR打上标签能帮助管理员管理提交队列。

• 基准影响：“no change"或者"change"标签
• 类别："bug","feature","documentation"
• 状态："draft","ready for review","ready for commit"

代码审查

代码审查允许协作者对拉取请求中提议的更改发表评论、批准更改或在合并拉取请求之前请求进一步更改。开发人员应解决审核者提出的意见。审核者应及时审核代码，以免延迟提交。

代码提交

代码更改经过至少一名代码审核者审核并批准后，即可合并代码。建议代码管理员在将代码合并到develop分支之前也审查并批准代码更改。

其它

UFS使用CMake构建软件。

参考资料

Making Code Changes in the UFS Weather Model and Its Subcomponents