Skip to content

Github Workflow Documentation

Jump to bottom Edit New page
Wesley Bondie edited this page Feb 14, 2015 · 1 revision

#Github Workflow Documentation

##Github feature branching model

  • All features related to game enchancements, bug fixes, etc will be branched by the following convention:
  • The issue will be filed before any git branching occurs.
  • Each branch implemented only one feature. (One Git issue)
  • The naming convention of branches are in lower-case (issueNumber_featureName) ex.14_test_feature
  • Each user will switch to their associated branch and commit development to the remote branch of their feature.
  • When your associated branch is ready to be merged into the game, you will create a pull request.
  • Each pull request will be code reviewed and tested by designers.
  • When your feature is approved, it gets merged into the milestone branch.
  • Every two weeks, a deploy is released with "release notes", effectively merging the milestone into the master branch, which is effectively the final game.

##Github Issue Standards All Issues filed under Github for features adhere to the following template: ###Description

  • A brief description containing what this features brings to the game, followed by what will be the end goal outcome of the feature being completed. ex. The pawn movement component is needed for the player to navigate around Soteria. The pawn movement component will allow players to move around the game space accurately, using a familiar control system.

###Requirements

  • Accurate list of tasks which will allow the feature to be considered "done".

###Previous Work

  • Previous work is for feature enhancements that derive from a base component of code already developed. ex. If I have already implemented moving, but I plan on implementing jumping while running in the game. This section should only contain file information

###Notes

  • Notes are required if the feature involves heavy collaboration or decisions in the design process. This section is for notes also related to implementation details.

##Trello board swim lanes Soteria has a total of eight swim lanes, each with a different purpose:

  • Asset Backlog - All of pre-developed assets will be listed in this card.

  • Backlog - All of pre-developed programming tasks will be listed in this card.

  • Ready for Development - Feature has been filed under Github issues, and is accurately ready to start implementation.

  • In Development - Feature is currently being worked on.

  • Ready for Review - Feature is completed, but has not passed a code review or asset standards test.

  • Testing - Designers are currently testing feature code branches for confirmation of completion.

  • Ready for Deployment - Feature is ready to be deployed at a future date.

  • Deployed - Feature completed. 🍺

##Trello integration with Github issues

  • The Trello board for Soteria should be reflected upon what is currently existing on the issue board in Github by using the following standards:
  • The feature name on Trello must match the feature name located on GitHub
  • All Trello boards relating to programming tasks deriving from the issue board will include the issue number at the end of the feature name. ex. Github workflow Documentation #6
  • The description of the card on Trello will be a link to the GitHub issue for easy linking to the features details located on Git.

##Artist Trello integration

  • Artists will be utilizing Trello only.
  • Trello will be a housing for asset production using the Asset Backlog
  • Each asset will move from there across the backlog into their appropriate lanes.
  • Assets do not have to go through the testing phase, as they will be placed inside of the milestone branch for designers to put them into the game.
Add a custom footer
Add a custom sidebar
Clone this wiki locally