Gitflow
Main assumptions
At first all feature branches are created from development (can be dev or develop). Branches that contains bug fixes can be created from staging or master branches.
Name of branch should contain task from Jira. For example, task/EA-967_website_updates. Possible prefixes for branch names: task, story, bug.
You commit messages should follow conventional commit guidelinesopen in new window.
Only team lead or lead project developer can have access to deploy branches (dev, staging or master). Other team members shouldn't try to push directly, only though merge request process.
Steps to create merge request
The dev will pull latest changes from development branch
The dev will create a branch with Jira issue id followed by issue type and title eg. task/UNIGHT-760_update_login_screen. Available types: bug, task, story.
The dev will fix the issue.
The dev will create unit and integration tests as applicable.
The dev will check that all new requests were added to Postman collection or Swagger for current project.
The dev will go through the checklist before creating merge request.
Before commit the dev will check changes made using
git diff, or IDE tools. Unnecessary changes should be removed from code (local changes make in secrets/credentials for testing, unnecessary logging etc...)Before commit the dev will check the status of changed files using git status or IDE tools, to ensure that all necessary files are added to commit.
The dev will switch to the development branch, pull latest changes from it and will merge it with his local branch fixing merge conflicts if needed.
The dev will ensure that the server runs locally without errors after the merge process.
If the unit and integration tests run successfully will create a merge request.
The dev will then copy the link of merge request and paste it into the backend-developers channel and tag @channel or to Team Lead direct messages.
The dev other than the one that owns the merge request will review it.
The dev that reviews will go through the checklist again and then review the merge request.
If there are any suggestions or any of the points of the checklist that are applicable but missed, the dev will comment on the merge request.
The owner of the merge request then performs the update again and resolves conflicts if any and again puts a fresh link in the same thread as the original one.
The dev that did the review will then do the review again and repeat from step 8 to 12 till the code review passes.
If the code review passes the reviewer approves and then merges the code and deletes the branch by keep the checkbox Delete source branch checked when merging.
Merge request checklist
My code follows the style guidelines of this project (to be decided)
I have performed a self-review of my own code.
I have tested the code locally.
I have commented my code, particularly in hard-to-understand areas.
I have updated Postman collection.
No dumps/logger calls.
KISS: Keep it simple and easy to understand.
Bad naming: make sure you would understand your code if you read it a few months from now.
No grammar errors.
Architecture errors: could there be a better separation of concerns or are there any leaky abstractions?
DRY: No repeat same patterns of code (Don't repeat yourself)
YAGNI: You aren't gonna need it, check that you are not over complicating something for the sake of 'making it future-proof.
No security vulnerabilities (Lack of input validation on user input, SQL injections etc...)
Complicated constructions that need refactoring or comments: code should almost always be self-explanatory
Forgotten TODOs and noop lines: make sure they're mapped in your Jira Issues board.
Did you update JIRA issue for this fix?