Branching Policy
Given the size of our coding team, we will be using a branching policy to facilitate the development of both the engine and the videogame itself. Additionally, detailed below are specific guidelines essential for ensuring effective practices.
- GitHub Repository: We will be using GitHub as our cloud-based Git repository, with GitHub Desktop chosen to facilitate the branching operations.
-
Master: The master branch represents the stable version of the build, free from bugs. If bug fixing is necessary, a branch should be created from the master, and the bug should be rectified as soon as possible. Furthermore, a pull request should be initiated with @Júlia Serra and the branch responsibles designated as the reviewers. If help is needed in order to do the pull request, please ask for help, remember that this is a team work.
-
Development: This branch serves as the primary space for feature development. Before creating a branch, please adhere to the naming conventions outlined for enhanced readability and productivity. Refer to the following link for detailed conventions: code-conventions.
-
Bugs: Bugs branch is dedicated to rectifying unintended behaviors detected within features during the development phase. Ideally, such issues should be identified during development. When a bug is identified, the coder should duplicate the development branch, isolate the bug, and address it separately. If the bug is discovered within the master branch, a new branch should be created promptly from master for bug resolution.
Adherence to these guidelines ensures streamlined development and maintenance processes throughout the project lifecycle.
-
Master: Should not be modified. Create branches from master in order to fix release bugs.
-
Development: Branches should be named as the feature it is currently developing in that branch. Avoid the use of develop-coder-name and properly use something similar as develop-animation-module.
-
Bugs: Bug branches should have the prefix bugfix- in order to identify that branch as a bug fixing branch. These branches should be made from the develop branches. If the master branch is the one that has the bug, create the corresponding branch from the master as bugfix-feature-master where 'feature' should contain the feature that is going to be fixed.
After creating the bugs branch, write an issue. Click code-conventions on how to write a proper issue.
For each commit, ensure comprehensive documentation of the changes made during that specific commit. Avoid superfluous commit messages such as 'I FINALLY FIXED IT', and instead adopt a structured format such as 'Fixed 'feature' by doing ...'.
Additionally, in the commit description, please write down the specific modifications implemented during the commit.
In cases where multiple persons have contributed to a commit, include the co-authors to reflect collaborative efforts and enhance productivity tracking.
Remember to verify that it adheres to the established coding style guidelines. This ensures consistency and readability across the code. Check code-conventions.
Issues serve as a means of communication for addressing encountered bugs. They should be documented within the designated section of the GitHub repository, at the issues section. When drafting an issue, provide a step-by-step account of how the bug manifests and the attempted solutions.
Assign the relevant code members who have identified the bug, specify the associated branch, and apply appropriate labels that succinctly describe the issue. This allows us to know who we should address in order to fix the bug or problem.
After finishing the documentation of the issue on GitHub, communicate its details within the issues text channel.
For guidance on composing issues, refer to the following link: Issue Composition Guidelines.