Conventions

Commits Convention

Commits messages

Git commits should only encompass one thing. The general convention for commits in this project is the first part of the commit message is surrounded by brackets and tells the reviewer what part of the code has been touched/modified. The next part is the type of commit it is, and that part is separated by a colon. Commit types are dictated by the Conventional Commits' standard types that can be seen in more detail on their website here. The last part of the commit message is a brief one-line summary of the action being done by the commit. If any more information is needed then that information should be told to the reviewer in the commit's body massage.

Proper commit messages examples

1. [Domain] feat: add User and UserDTO classes
   The example above first part indicates that this commit changes one or more files in the /Domain directory. The second part of the commit message tells us that this commit is a new feature indicated by the feat: keyword. Next, add User and UserDTO classes the third and final part of the commit message gives us a summary of the action that has been performed in the commit, and in this case, the developer is telling us that he/she created a new class for the User to be stored in the database and a class for the User to be sent to other parts of the code base as indicated by the DTO part of the class name.
2. [UserController] feat: get overall accessibility Score by user id
   The commit example above it telling us that this commit is changing code in the UserController file; moreover, the next part feat: once again indicates that this commit like the last example is also a new feature commit type. The final part of this commit message tells us that the developer adds changes to the UserController file so that the API client can now get the overall accessibility score of a user by providing the API with the exact user id of the user the client is attempting to get the overall accessibility score for.
3. [Database] refactor: split AccesibilityScore table
   Again, the first part of the commit message tells us where the changes are being taken for the commit. In this example, the changes are being taken in the /Database directory. Secondly, the next part indicates the type of commit and in this case, unlike the first two examples, this commit is a refactoring commit as indicated by the refactor: keyword meaning that this commit just restructures already exciting code as does not contribute to any new features to the code base. Lastly, the commit's message split AccessibilityScore table tells us that the developer split up the AcessibiltyScore table class into separate classes. How many classes? What stayed and what did not? Great questions; however, these general questions' answers should be found in the commit body message and not the commit header message.

Pull Requests (PRs) Convention

Naming a Pull Request

Pull Requests names should go as follows the first part should be surrounded by brackets that tell the reviewer what the main directory the PR is encompassing. The second part is a summary of the PR. The first comment should be a full summary of the PR and should be commented on by the developer that created the PR. Afterward, the PR must be reviewed by another developer and all code change requests have been resolved before the PR can be merged into the main branch.

Proper PR name example

[/API] Integrate open API C# ASP .NET Core (backend)
In the example above the first part surrounded by brackets tells the reviewer that the directory being worked on is the API directory. The PR summary is Integrate open API C# ASP .NET Core is exactly as you suspect, it ingrates the API portion of the project into the repository.