Git Practices and Conventions

The git workflow that we will be following can be found here. The general steps of this flow is as follows:

• Fork and clone the main repository
• Create a new feature branch every time you start work on a new issue. Feature branches should follow the convention of {issue-type}/{issue-number}-{issue-title} eg. If you have an issue which is a bug with number 30 and title Fix Headers your branch should be named bug/30-Fix-Headers. You should branch from master.
• Make your changes in the feature branch in your local clone. If the change is large, consider using a feature flag and multiple pull requests.
• Update your local repository with the most recent code from the main repository. Remember to rebase often - don't wait until all changes have been made.
• Test your changes - run all existing tests and any new tests you have created, run the code and make sure the application works as expected.
• Create a pull request. The pull request should have a title which summarises the changes. The body should provide more details about what changes have been made and should reference the number of the associated issues, eg "Fixed synchronization issue closes #123". The tile of the pull request should not just reference the issue number - it should succintly describe the actual changes.
• Another team member must review and approve of the pull request.
• Once the reviewer approves the pull request, they can merge your contribution into the main repository. Do not merge your own pull requests. Your team may give all contributors merge access or decide to allow only a subset of team members to merge contributions. This should be agreed upon by all team members and documented in the project documentation.