Wiki

Clone wiki

pflotran / Developers / CodeDevelopment / VersionControlGuidelines

General Guidelines for Administrating Version Control on a Git Repository

  1. Administrator: Each repository will have an administrator who possesses administrative privileges for a repository. Only the administrator can modify the master branch of the repository. The administrator will review all proposed changes submitted through formal pull requests against the master branch of a repository.
  2. Developer: The developer will adhere to the following steps when making changes to a repository.
  1. Create a branch. The developer will create a development branch that originates from the master branch of a repository (or fork the repository). In the case of a development branch, the naming convention should follow “developer/brief-description” (e.g. john/integral-flux-refactor). Developers will have permissions to push these development branches up to the main repository for sharing among developers.
  2. Modify the branch. The developer will modify the development branch/fork (bug fixes, new features, etc.).
  3. Update testing. If unit, regression and/or verification/validation (V&V) testing exists, the developer will (a) add new unit, regression and/or V&V tests that cover implemented features or (b) update gold files for bug fixes.
  4. Update documentation. The developer will update all documentation to ensure consistency with the current state of the code.
  5. Submit a pull request. The developer will create a pull request that asks that the development branch be reviewed by the administrator and merged to the master branch of the repository.
  1. Administrator: The administrator will review the pull request for accuracy and consistency.
  1. Scrutinize new process models for accurate and efficient implementation.
  2. Check for consistency with coding standards.
  3. Ensure that testing is in place and that all tests pass.
  1. Administrator: The administrator accepts the pull request.

Notes

  • Administrators must follow the developer steps when making their own changes to the repository. Ideally, they request that another developer review and approve their pull request prior to merging it to the master branch. Most all code collaboration tools allow for additional reviewers beyond the (default) administrator.

Terminology

branch: A Git repository can be viewed as a series of commits that are connected or linked to form a tree graph structure. The main branch of the tree is often termed the master branch while temporary feature branches originate from the master branch. These feature branches can be merged back into the master branch or pruned (discarded) from the repository if unneeded.

fork: A fork is a clone of a repository that resides on the same code collaboration tool (e.g. GitHub) under a separate name or account.

pull request: Bitbucket and GitHub refer to a request to merge a development branch or fork against another branch or fork as a “pull request”, while Gitlab describes it as a “merge request”.

Updated