Mission Development SOP - 7Cav/7Cav-Alive GitHub Wiki

Standard Operating Procedure

Setting up Github Every team member must be assigned to a GitHub repository where they are required to make changes and updates. When first assigned to a repo, a given team member must create a new branch with their name and it to origin, examples below. EG davidcit-patch, davidcit646, davidcit-featureAddition

When Pushing a change Every team member must push changes in a repo to their own branch, which will be named after them. If one such branch does not exist in the current project that has been assigned to them, then they may create a branch with their name and push it to origin so that they may push changes to that branch. EG davidcit-patch, davidcit646, davidcit-featureAddition

When testing changes When all proposed changes are pushed to a given branch, they must be tested by two or more team members. If a given test is not approved then changes must be made and tested again, whereupon pending approval, a pull request must be made.

When submitting pull requests into “Develop” Pull requests are to be submitted after all of the proposed changes are fully completed and tested. When submitting a pull request, you must follow the given template, this helps everyone know what work is being done in regards to publicly tracked issues

When merging pull requests into “Develop” Github admins are required to merge pull requests only after the proposed changes have been fully reviewed by two separate parties. Pull requests submitted by a given team member cannot be reviewed or approved by the team member who submitted the pull request.

When Dealing with issues on Github Upon receiving an issue on any of the repositories, the following will take place: Github clerks will check the validity of the issue and if there is a similar issue already present. If the issue is a duplicate, it will be closed, whereupon a link to the original issue posting will be listed inside a comment. After the issue has been verified as genuine, the issue will be assigned to a team member from the respective team (public or training), and assigned to a project & milestone. When the issue is being worked on by the respective team member, the team member must move the issue to “in-progress”. When the issue has been worked on and is ready to be tested, the respective team member must submit a pull request to the develop branch, and request other members to review it. This will move the pull request into ‘Quality Assurance’ Automatically. If a member of either the training team or the public team sees an issue and would like to work on it, they must first: Assign themselves to the issue. Move the issue to “in-progress”. Submit a pull request to the develop branch, and request other members to review it. This will move the pull request into ‘Quality Assurance’ Automatically.