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.
...
The last argument is the hash of the commit that first introduced the bug. If that was a tagged version, you can use the tag name as for the feature branch above. Bug Unlike new feature development, bug fixes are typically never started from the HEAD of master.Advanced developers can branch off of alternate places if they know what
It is ok to fix multiple bugs on a single bug fix branch if it makes sense to do so (e.g. one related set of code changes can fix multiple bugs.)
Advanced developers can branch off of alternate places if they know what they are doing.
NOTE:
Creating a new branch will not change the current branch that is being worked on in the current working directory.
...
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 for the integration of your project into master.
A pull request initiates a request to merge your branch into master. It is documented in github issues in combination with the subsequent code review and discussion, and the outcome of the pull request.
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 all your changes and pushed the branch to the shared repository, you can navigate to the shared repository on github.
Go to https://github.com/ACME-Climate/ACME/pulls and click "New Pull Request".
You should verify the head and base of your pull request are correct. The pull request should also be provided with a very descriptive message and title. 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.
If the PR is fixing a bug and the bug # was not mentioned in the commit message, include it in the description.
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.
This document can be used to help with pull request related issues.
Minimum Code Review
When a developer is finished with a branch, he/she makes a "pull request" (PR) to have the code integrated and uses GitHub to assign an Integrator to the PR.
...
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.
...