Skip to main content

Code management

Git Workflow​

This section of the document will be written by some development patterns that will be used in the project's development process. For starters, all the developers must push all their code to the private repository at the end of each day. That's because it will give the project manager time to check the development of the team and it will make sure that the code is on its latest version, and that reduces a lot of merge conflicts that may appear. The repository has 3 permanent branches:

  • Main
  • Prod
  • Dev
  • Main
  • Production
  • Beta Public Limited Private Internal Alpha Limited Private Internal
  • Main

This branch has the production code on it, ready to be used by the user. This branch cannot be used for development. The only persons authorized to use this branch are the Project Manager, the project's technical leaders or a chosen developer. The only components that should go into the main branch is the merge with the prod branch.

Prod This branch contains the final production code, ready to be used by the user and ready to be merged with the main branch. The only persons authorized to use this branch are the Project Manager, the project's technical leaders or a chosen developer. Dev This branch contains the latest version of the development of the application. It is from this branch that the developers can create new branches for building features, fixing bugs and testing the components of the application. However, the development team cannot merge any branch with the dev branch unless the Project Manager or the project's technical leaders gives permission to do so. This branch, when evaluated, is to be merged with the prod branch.

Auxiliary Branches​

The auxiliary branches are used for building features, fixing bugs, testing components and managing other situations that can appear during the development process. All these branches have a limited life. As soon as the problem is solved or the feature is ready, this branch needs to be merged with the dev branch, so the other developers can work on the latest version of the application. The branches need to be clearly named (names that can't be used are: master, main, dev, developer, development, release, sprint, hotfix, names not related to what the branch is supposed to do), and each branch must be specific to only one function. They need to follow this pattern:

feature/nameOfTheFeature fix/nameOfTheBug Feature Feature_Beta Public Limited Private Internal Feature_Alpha Limited Private Internal Dev Dev_Feature_Beta Public Limited Private Internal Dev_Feature_Alpha Limited Private Internal

Commits​

To keep the git history legible, the commits will have a pattern. This pattern has two parts, the type and the description.

Type

The type can be one of these options: feat: new feature or new update on a feature fix: bug fix refactor: code refactoring update: packages, configs, build, etc updates. (None code alteration of any functionality) test: addition, refactoring, removal of tests. (None code alteration of any functionality)

Description The description should answer the question: "what was done?" and if possible, answer "and why?" too. Be as short and concise as possible.

An example of how the commits should look like:

feat: pagination on the home page started. fix: fixed the primary colour on the dark theme refactor: eliminated unused code to clear space in the project. update: updated all the packages in the pubspec.yaml to avoid conflicts test: testing all search possibilities