Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: number the PR steps

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.

...

Commits that occur prior to a merge cannot be modified, or rebased. In general, if you previously merged within your branch (i.e. to incorporate an “external feature”) or if your branch was previously merged into another branch, you should not rebase anymore, because it will cause conflicts during future work.

Finishing Up

Submitting a pull request (PR)

Once you think development is finished on your branch, you should push the branch to the shared repository (a remote), and submit a pull request (PR) for the integration of your project into master. 

...

Pull requests should consist of commits that somehow "go together". It's fine if a single PR fixes multiple bugs or provides multiple features but try not to get carried away (it's hard to review a 100-commit, 10 kLOC pull request).To make a PR: Once you have committed

  1. Commit all your changes and

...

  1. 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.   By default, it will use the title of the most recent commit.  You should change this if its not descriptive enough. DO NOT include github issue #'s 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 commit.  The reviewer will review the description as part of the pull request, because the description will be the commit message used when the merge is finished.   See merge commit in Commit message template
  6. After the description of the feature, add a brief statement on how the feature was tested.  Example:  acme_developer on Titan passed.
  7. 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  
  8. When complete, click on "Create pull request".
  9. 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.
  10. 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.

...

  1.  

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. pushpull, and fetch.

...