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.
...
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.
...
git merge-base github-username/component/my-feature ACME-Climate/ACME/master
Will will tell you the commit that is the base of your branch. If you perform an interactive rebase onto the merge base, you can modify the history of your branch without introducing merge conflicts associated with changing your base. For example:
git rebase -i $(git merge-base HEAD ACME-Climate/ACME/master)
will rebase your branch using the tip of the ACME master branch as its base. Finally, modifying code might require introducing new commits, or editing previous commits.
Editing existing commits
Occasionally, you may need to change one of the commits you've made. For example, if you added a file that shouldn't have been added to the repository, you may want to eliminate it from the commit to prevent it from being tracked in the repository's history.
There are several ways to edit an existing commit. In general, the commands you use are case specific, so general commands cannot be provided. Instead, general command usage and guidelines will be provided, but the integrator helping with the pull request should be able to give more information about specific commands.
One way to edit existing commits is to interactively rebase a branch onto it's own base, which is found using the merge-base command in the above section. After typing the rebase command, a text editor will open with several lines. Each line represents a commit that git will allow modification for. The lines can be broken down into the following information:
action hash subject
The hash and subject provide information about each commit so you know which is which. The listed on each line is an abbreviated hash prior to the rebase. The subject is the first line from the commit message for that commit. On each line, action tells git what it should attempt to do with the specific commit. Available actions depend on your git version, but all of them start with a default value of pick. Pick means git will "cherry-pick" the commit and leave it as is. In this case, we want to change pick to edit on the commit we need to modify. After selecting this, we can save and exit the text editor. Git will then attempt to rebuild the branch with the selected actions.
When git encounters the commit we selected edit for, it will stop and allow modifications to the commit. The edits can be made by amending the HEAD commit (i.e. make changes and `git commit --amend`). After the commit is left in the desired state, the rebase can continue using `git rebase --continue`.
It would be nice to have a worked example here to make things a bit less abstract.
Testing a feature
After a reviewer is satisfied with all parts of a pull request, both the reviewer and the developer will perform testing on the pull request. The developer may be required to point a reviewer to a specific test case or namelist that can help the reviewer test the feature.
...
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.
...