Page Comparison

This document provides details on ACME 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.

...

1. Commit all your changes and push the branch to the shared repository, 
2. go to https://github.com/ACME-Climate/ACME/branches and find your branch.  Click on  "New pull request".
3. You should verify base and compare of your pull request are correct.  The "base" is master and "compare" is your branch.
4. Enter a PR Title:  Make sure the title is 70 characters or less and explains the feature you are adding. A default title will be created for you. PR in a "verb noun" format like "add cool new feature". Do not just use the branch name or what is filled in by default.  (If your branch has a single commit, the title of that commit will be usedthe default, but if your branch has multiple commits, the branch name will be usedthe default.)  You should edit the title to make sure it is descriptive enough. DO NOT include github issue #'s or JIRA tasks in the title. Hyperlinking does not work from the title.
5. Write a PR Description.  In the "Write" field, provide a very descriptive message . By default, this will have the description of your last commitof what all the commits in the PR will do together.  The reviewer will review the description as part of the pull request, because the description will be used in the commit message used when the merge is finishedPR is merged to next and master.   See merge commit in Commit message template
   1. After the description of the feature, add a brief statement on how the feature was tested.  Example:  "acme_developer on Titan passed".  If a test is expected to fail and required redoing baselines, state that and list the tests that fail.
   2. If the PR is fixing a bug, add a blank line after the above content  and then include the github bug # with the word "Fixes".  Example:  Fixes #89 
   3. After the bug fixes, if this PR will change answers or namelists, add the keys  "non-BFB", "CC" or "NML" depending on if the answers change to roundoff, are climate changing, or change a namelist, respectively.
   4. On the last lines, add any JIRA issue keys that are associated with this PR.  Example,  OG-56, LG-47, SEG-78.
6. When complete, click on "Create pull request".
7. After submitting the pull request, navigate to its page in github and give it a Label using the pull down menu there.   Label it with the component for which the feature was developed.  Add the "bug fix" label if this is a bug fix.
8. Using the "Assignee" menu, add the name of the designated Integrator for your component.  See Integrator Guide for a list.  This will start the code review and the process of moving this feature to 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.

...

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.

...