Pull request conventions - Developer Guide - Cortex XSIAM - Cortex - Security Operations

Always create PRs from your own fork using a dedicated branch. Do NOT use the master/main branch.

Use clear and brief messages for your commits. See this article for good examples.

Do NOT use force pushes (i.e. git push --force): if you are in a situation where you need to force push, reach out to us and ask (in the pull request itself or via Slack).

During the process our reviewers might ask for multiple changes. Work through the entire list and commit all the changes.

When you push changes to your fork's branch that was used to open the PR, the PR is automatically updated, you don't need to open a new PR. Do NOT open a new PR unless absolutely necessary (i.e. unless asked by the reviewer), as it will make it hard for the reviewer to track their comments.

The review usually has a summary and several conversations: make sure you address all the comments, including the ones in the summary:

When addressing the review's conversations, do NOT mark them as resolved. Write done in a comment, so the reviewer can keep track of them.

Once you have pushed all requested changes, please ask for a new review by navigating to Reviewers section in the right sidebar in GitHub and click the  icon next to the reviewer's name.

If the branch you'll be using as the basis for the pull request includes more than 50 commits, squash all commits into a single commit before creating the pull request. This makes the git history cleaner and easier for reviewers. Below is an example of a squash merge after consolidating 122 commits into one:

COMMITS=122

git reset --hard HEAD~$COMMITS

git merge --squash HEAD@{1}

git commit -m "squash last $COMMITS into one"

Alternatively, you can use a specific commit to squash from:

COMMIT_HASH=0d1ddfc42

git reset --hard $COMMIT_HASH

git merge --squash HEAD@{1}

git commit -m "squash from $COMMIT_HASH into one"

ci/circleci: Run Unit Testing and Lint

ci/circleci: Run Validations