Version Control Conventions

Git workflow conventions

This document outlines rules that each member of the team should abide by to provide a smooth development experience for everyone

Gitflow structure:

We will be working with CI/CD workflow where we will try to test our project as a whole as much as possible. the plan is to have rapid development workflow and a pipeline for automated build processing.

We will have a master branch where we will have major releases pushed to We will have a develop branch where we will work on constantly.

seperate temporary branches will be made and deleted once no longer used.

Branch naming convention:

All branch prefixes should be lower-case

Example:

Good: feature/UI

Bad: Feature/UI

Branch names should be always PascalCase

Example:

Good: feature/PlayerPhysics

Bad: feature/playerPhysics or feature/Playerphysics

Branches should not include any spaces or hyphen or any unnessicary slashes after the prefix:

Good: art/PlayerModel

Bad: art/Player/Model or art/Player-Model or art/Player_Model

Workflow

Dev workflow

When creating a new feature a branch is needed to make since we dont want to apply changes to development directly. this branch will have the prefix of feature/ to indicate that this is a feature

When needing to modify something on the dev branch there should be a seperate hotfix branch on the requested change with the prefix hotfix/

Artist workflow

When adding a new asset related to Art the branch should be created with the prefix art/

When a asset needs some modifcation a branch should be made with the prefix artfix/

Scene conflicts:

in each branch a duplicate scene should be made of the main scene. this temporary scene will act as a working space with the most up-to-date changes and should include any nessicary changes you might want to include.

when eventually merged the integration of these scenes will manually be implemented inside the mainscene by the lead developer and pushed directly to develop.

These scenes should be in their respective folder of branch prefixes so feature/main-menu should have a scene in the features folder named mainmenu

Pull requests:

When merging a branch to development a pull request must always be made, if the branch is a feature/ or hotfix/ the lead developer should check it and approve it by checking the code and potentially playtesting. when the branch is a art/ or artfix/ the lead artist should check on it if the art is corectly implemented inside the game

Draft vs Ready for review

When creating a pull request make it a **draft pull request** if it is not ready to be reviewed yet or its worked on. only when a pull request is ready to be reviewed can you switch it to **ready to review**.