Before Start Programming

  1. Write a design document and verify it with all others. Please use the following Template for your document.
  2. Create issues for your implementation to track the progress. Adhere to the template questions provided when the issue is created.
  3. In addition, include the following content in the issue:
    1. A brief description of why the issue is required.
    2. Any external links or documents complementing the content of the issue.
    3. A set of acceptance criteria used for validating the pull request.
    4. A component label to which the issue belongs (E.g., optimizer, state-management, etc.).

Scheduling

Common mode: If the issue is created, and you want to work on it, you have to groom it in a scrum meeting. You will present and describe the issue to the others in this meeting. If everybody knows what has to be done and the acceptance criteria are clear, we will schedule the issue for the next sprint. Then, you can start working on it.

Bypass mode: If the change is a hot-fix or required bug-fix, the issue can be directly worked on but has to be scheduled in the current sprint board.

Coding

  1. When the issue is groomed and scheduled, you can create a new branch and start coding.
  2. Start your branch name with the issue number, for example, 123-my-awesome-feature.
  3. While committing changes to your branch use the issue number before the commit message, for example: “#123: added a new method to support my awesome feature”. You can also use Add Issue Number Automatically.
  4. Add descriptive commit messages and avoid committing with unspecified messages like “test” or “fixed.
  5. Make sure you adhere to the Coding Guidelines.
  6. Make sure to use the right log level Logging.
  7. Ensure all tests are green in debug and release build (the CI will run the release build). Monitor the status of the CI builds for your pull request. If it fails, please investigate why.

Review

Once you are sure that your code addresses all criteria of the issue, open a PR and link the issue to it. Request review from at least two people and address their feedback until you get their approval. If you have received approval from at least two reviewers, you can either merge your PR into the master or ask an admin to do so. Usually, the review process takes several iterations. Please, remember that we cannot merge pull requests that fail our CI for any reason. Respond to comments left on the pull request from team members. Remember, we want to help you land your code, so please be receptive to our feedback. We may ask you to make changes, rebase, or squash your commits.

Rule for comments:

  • If you did what the reviewer asked you, you can resolve a open comment.
  • If you did not understand what the reviewer asked for or there is the need for a discussion, contact the reviewer or reply with a comment.

Updating the Code

If we ask you to make code changes, there’s no need to close the pull request and create a new one. Just go back to the branch on your fork and make your changes. Then, when you’re ready, you can add your changes into the branch:

git add -A
git commit
git push origin issue1234

When updating the code, it’s usually better to add additional commits to your branch rather than amending the original commit, because reviewers can easily tell which changes were made in response to a particular review.

Updating the Commit Message

If your commit message is in the incorrect format, you’ll be asked to update it. You can do so via:

git commit --amend

This will open up your editor so you can make changes. After that, you’ll need to do a forced push to your branch:

git push origin issue1234 --force-with-lease

Rebasing

If your code is out-of-date, we might ask you to rebase. That means we want you to apply your changes on top of the latest upstream code. Make sure you have set up a development environment, and then you can rebase using these commands:

git fetch origin
git rebase origin/master

You might find that there are merge conflicts when you attempt to rebase. Please resolve the conflicts and then do a forced push to your branch:

git push origin issue1234 --force-with-lease

Finalization

  • Once PR is accepted and the changes are merged, please make sure to delete your branch to keep the repository clean.

How to add the issue number automatically to your commits

  1. Open .git/hooks/commit-msg
  2. Paste the following code:
#!/bin/bash
BRANCH_NAME=$(git branch | grep '*' | sed 's/* //')
COMMIT_FILE=$1
COMMIT_MSG=$(cat $1)
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
ISSUE_ID=$(echo "$CURRENT_BRANCH" | grep -Eo "([A-Z]{1,10}-)?[0-9]+")
if [ $BRANCH_NAME != '(no branch)' ]
then
if [ ! -z "$ISSUE_ID" ]; then
  echo "[#$ISSUE_ID] $COMMIT_MSG" > $COMMIT_FILE
  echo "ISSUE ID '$ISSUE_ID' prepended to commit message. (Use --no-verify to skip)"
fi
fi
  1. Delete .git/hooks/commit-msg.sample
  2. Execute chmod +x .git/hooks/commit-msg
  3. Make sure your branch name begins with the issue number, example: 123-my-awesome-feature.

Git Configuration

Please make sure that you have git configured as follows:

git config --global pull.rebase true
Edit this page on GitHub
←
→