This page describes rules to create Pull Requests.
Commit naming rules are presented here
We use next commit scopes:
- kb - knowledge base updates
- solver - Problem Solver updates(C++ and Python agents)
Update this docs via pull request for add new scope.
You can do not use scope. For example feat: ..., fix: ...
Each commit should have not much differences excluding cases, with:
- CodeStyle changes;
- Renames;
- Code formatting;
Do atomic commits for each changes. For example if you rename some members in ClassX and ClassY, then do two commits:
fix(<scope>): rename members in ClassX according to codestyle
fix(<scope>): rename members in ClassY according to codestyle
Do not mix codestyle changes and any logical fixes in one commit
All commit, that not applies to this rules, should be split by this rules. Another way they will be rejected with Pull request.
- Read rules to create PR in documentation
- Update changelog
- Update documentation
- Create PR on GitHub
- Check that CI checks were passed successfully
- Assign PR reviewers
- Send link to PR to project development chat
- Reviewer should test code from PR if CI don't do it
- Reviewer submit review as set of conversations
- Author make review fixes at
Review fixescommits - Author re-request review
- Reviewer resolve conversations if they were fixed and approve PR
- Author can update commits history for remove
Review fixescommits - Author merge PR to base branch
- Author test work at base branch