This document provides details on ACME development conventions and practices.
...
As always, it’s a good idea to understand what you’re doing before you do it. This document should not take the place of understanding, but can be used to learn and remember.
How to use this document
Within this document there are sections you can refer to when attempting to perform repository actions. The ordering is intended to closely resemble a typically feature development cycle, though some tasks may or may not exist in the development of all features.This document expands on portions of the Development Quick Guide providing more detail on ACME development workflow. You should read the Quick Guide first, and use this document as needed.
Specific pieces of information will be colored as follows:
...
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.
...
Once you think development is finished on your project, you should push the project to the shared repository (a remote), and submit a pull request (PR) for the integration of your project into master.
A pull request initiates a request process to merge your branch into master. It is The PR and process will be documented in github issues in combination with the subsequent code review and discussion, and the outcome of the pull request.
...
To make a PR: Once you have committed all your changes and pushed the branch to the shared repository,
Go to https://github.com/ACME-Climate/ACME/pulls and click "New Pull Requestbranches and find your branch. Click on "New pull request".
You should verify the head and base of base and compare of your pull request are correct. The pull request should also be provided with a very descriptive message and title. The The "base" is master and "compare" is your branch.
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.
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
If the PR is fixing a bug and the bug # was not mentioned in the commit message, include it in the description.
When complete, click on "Create pull request".
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.
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.
...