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.
...
The E3SM repository will have one or more active maintenance branches usually to keep adding bug fixes and machine updates to old versions. See Existing and Planned Tags and Branches for the list of branches and , their purpose and what kind of changes they will accept.
If one of the maintenance branches needs features added to it, make a branch from the head of the maintenance branch. You do this by first checking out the branch by its name.the feature, machine update or bug fix you are working on needs to go on a maintenance branch, switch to that branch before making your feature branch. For example:
git checkout maint-1.0
This will put your working directory at the head of the maintenance branch. You can then start a new branch as you do for master. When you make a pull request, specify the maintenance branch as the "base".
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 developing 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.
...
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.
...