This document provides details on E3SM development conventions and practices.
...
important -- Items colored in red mean they are important, and should not be ignored.
one time -- Items colored in green are commands to be issued once per machine.
repo once -- Items colored in orange are commands to be issued once per local repository.
...
If you need to fix a bug on a maintenance branch and the bug was introduced by a commit on the branch, you can follow the same directions as for a bug-fix branch.
If you are development something for both a maintenance branch AND master, do the maintenance development first. You can then ask the integrator to merge maint to master. Or you can make 2 pull requests, one for maint and one for master.
If your development depends on something that was added to master AFTER the maintenance branch started, it can not be added to the maintenance branch. Master "contains" the content on the maintenance branches (if they are not too old) and one can merge from maint to master. We can not merge from master to maint.
IMPORTANT: We do not have "next" branches for maintenance branches to test multiple features against each other. To compensate, all development on a maintenance branch should be done sequentially. That is, one developer makes their branch, completes the feature, tests it and then has it integrated to the branch before the next development starts. This should not be a problem because maintenance branches are not supposed to have heavy development. You should always test feature branches but this is more important for maintenance features since there is no "next" testing and you don't want to break the maintenance branch by integrating a broken feature.
...
Your PR is not finished until it has been merged to master by the Integrator.
This document can be used to help with pull request related issues.
...
- Check the github entry for the PR and make sure it has a good title and description, correct labels and a comment with a link to the Design Document. A PR can not be merged to next or master unless it has a Design Document with Phase 1 and 2 completed. See /wiki/spaces/CNCL/pages/25231511.
- Look at the code changes either on github or using: git log --reverse -p master.. on your checked out copy of the branch.
- Does new code hold up to visual inspection for code quality? Look over code changes for glaring mistakes or code style issues (e.g. useful comments, reasonable subroutine lengths, new code in an existing file follows conventions of that file).
- Check to see if the description of the code changes in the PR match the actual changes. Make sure nothing unrelated to the PR was committed accidentally.
- Although they can't be changed, see if commit messages on the branch follow the Commit message template and let the developer know if they can not. Consider asking the developer to squash commits to clean up the history.
- Have tests been added or suggested that exercise this feature?
- Does code run on all platforms after integration into next?
...
Before communicating with remotes, you might want to add or remove remotes. In order to add and remove remotes the git remote command can be used. The two uses are as follows:
git remote add remote-name protocol:address/to/repo # Creates a remote
git remote remove remote-name # Removes a remote
In order to communicate with remotes, there are three actions. push, pull, and fetch.
...