Github Workflow Standards - Light-and-Sneak/light-and-sneak GitHub Wiki

Workflow Standards

These standards are the ones we adhere to in the CS-Club here at IUPUI. The standards defined below are mandatory, and anyone who works on this project are required to adhere to these standards. The central focus is to Keep Master Clean.

Issues

The way that projects are often organized is the high level requirements of the project are broken down into individual tasks called issues. These issues are then assigned to individual collaborators or a collaborator can pick up an issue.

Branches

The collaborator will then create a branch from the master branch, this allows the collaborator to work on the task and make changes to the project without affecting the master branch. If the issue you are working on is dependent on a branch that has not yet been merged into master, you will create a branch from master, merge the branch your issue is dependent on into the newly created branch, then implement your issue.

The naming standard for the branches should be: issue<number>-<featureName> where the <number> is the issue number and the <featureName> is the name of the feature you're working on. I.e issue7-login-authentication

Collaborators are never permitted to work directly with master ever.

Pull Request

Once a collaborator has completed their task they will push their branch to github and create a pull request from their branch to dev. Once the pull request has been created, it will require one of the administrators to review and approve of the pull request. At this point the reviewer can also leave comments in the pull request, stating changes that may need to be made or inquiring for the reason why the collaborator chose to do something.

If there are comments, address all comments on the same branch. After addressing the comments, update the comment stating that you have addressed the comment. Remember to push the modified code to the remote branch. This should update the original pull-request with the newly modified code.

Once the pull request has been approved by an administrator it is the collaborators responsibility to merge the pull request.

Merging to master

To reiterate once again, the central focus is to keep master clean The master branch is the working branch, and will be deployed to the server Either at the completion of a feature, or near the end of a sprint, dev will be pulled into master

⚠️ **GitHub.com Fallback** ⚠️