The way GitLab CI is supposed to work is that you have a
gitlab-ci.yml file in your repo with pipeline instructions for what GitLab should do when your repo gets pushed or a pull request is submitted to your repo. The pipeline is specific to each branch and will execute only on the branch to which you've pushed changes unless you've configured it otherwise. You can have entirely different pipelines for different branches. You can also manually run the jobs from within GitLab or via API, as you've been doing, but the power of it is that it runs automatically in the background on every code push.
What GitLab does with your repo is that it spins up a Docker container, clones your repo into it, runs whatever instructions you've given it, and then takes the artifacts it's generated, such as a build or test result, and makes them available to the next step in the pipeline, which could be pushing it to your server or your test coverage tool.
From what you're describing, and please correct me if I'm wrong, but it sounds like you're using your pipeline to alter the actual contents of your repo itself. I'm not sure that's the best move. The point of the pipeline process is to run tests, builds, and deployments. You can use it to push a package to NPM, or upload fresh code to your web server, or check your code for vulnerabilities. But I wouldn't use it to actually change code in the repository directly because the unintended side effects could be disastrous.