Git Workflow with Acquaman Issues

This page details the workflow of an issue from creation, through testing, to completion. Sticking within this general workflow makes the management of issues and the tracking of changes as simple as possible.

The life of an issue

In Acquaman, in general, issues should follow a general path:

• Problem/feature request is noted by a user of the system.
• An issue is added to github with as much information as is reasonable, detailing the issue. (see Creating an Issue)
• The issue is claimed by a member of the Acquaman team on github.
• That team member creates a local branch with the name "Issue###", where ### is the number the issue is assigned by github (see Creating a Local Branch for an Issue)
• The team member makes changes within that branch, committing at logical intervals with a reasonably descriptive message. (see Committing Changes to an Issue Branch ).
• Each of these commits are pushed up to the remote repository, in order to provide a remote backup of work, and to allow code review by team members. (see Working With the Remote Acquaman GitHub Repository)
• Once the team member believes the issue to be fixed they mark the issue with the "Awaiting Testing" label in github
• The team member can then pull this issue from the remote github repository and test it on the beamline. (see Working With the Remote Acquaman GitHub Repository)
• When confident that the changes have been sufficiently tested, the team member can create a pull request for the issue to be merged back into its parent. (see Creating Pull Requests)
• When the branch has been in production for a sufficient length of time to be confident of its correctness, the branches can be deleted from the local and remote repositories. (see Cleaning Up Local and Remote Branches)