Gitflow model
- master stores the official release history
- koni-dev serves as an integration branch for features
- tag all commits in the master branch with a version number
- default branch: koni-dev
- each new issue should reside in its own branch name koni/dev/issue-xxx (xxx is issue number)
- koni/dev/issue-xxx branches are generally created off to the latest koni-dev branch
- when a issue is resolved, it gets merged back into develop
- koni/dev/issue-xxx should never interact directly with master
- When creating a pull request, you add a brief overview of your feature, select the branch to which the code needs to be merged, and select the assignee who will be reviewing it.
- Once it is created, it is open for discussion or modifications.
- Sometimes conflicts occur after creating a pull request, and you must resolve these conflicts by commit resolved code.
- Usually, the assigned person reviews the code, but it is not mandatory that only the assignee performs the review. Any team member can take part in the review process and give their feedback or discuss potential modifications to the code.
- Any feedback or modifications are added in the form of comments near the code line.
- The developer resolves comments and replies to the reviewer.
- This process continues until all comments are resolved.
- Once all discussions are resolved, the code is merged to the branch that was selected when the pull request was created.
- Develop Branch: A pull request is created by developers from their respective feature branches to merge code to the develop branch. Usually, it is created after features are completed. A pull request is merged to the develop branch by the reviewer. In most cases, a reviewer is a technical lead.
- Note: Although it is possible to skip pull requests and push code directly to branches, they shouldn’t be avoided as they provide better quality and stability for code.