how to differentiate when the MR is accepted

I'd like to have a branch in the deployment script of my .gitlab-ci.yml file that is based on whether the particular pipeline is run because a MR has been accepted and is being merged into the default branch.

For instance,

Deploy:
  stage: deploy
  image: alpine
  script:
    - apk add openssh-client
    - install -d -D -m 700 -p ~/.ssh
    - eval $(ssh-agent -s)
    - cat "${MY_SSH_PRIVATE_KEY}" | ssh-add  -
    - if [ "${CI_DEFAULT_BRANCH}" = "${CI_COMMIT_BRANCH}" ]; then \
         rsync $BUILD_DIR/myfile.tar.gz filestore1 ; \
       else \
         rsync $BUILD_DIR/myfile.tar.gz filestore2 ; \
       fi

I don't think that the comparison of CI_DEFAULT* with CI_COMMIT* is a safe comparison. I believe this works anytime a commit is on the default branch, not when being merged, so I think I'm missing an important distinction and/or a best-practice.

My intent is that so long as the MR is still in dev, it should be pushed to filestore2, and only pushed to the production filestore1 when the MR is good, tests good/complete, and is accepted.

Related:

• Gitlab: How to run a deploy job on a tagged version / release? requires me to tag when I need to release something; this may be something I work into my workflow, but is not our current workflow