We use git. Deployments to any shared environment can only take place from the main/master branch.
We develop in short-lived branches and a lot of automated tests and QA tasks. The automated stuff must pass. Some people refuse to look at a pull request until these pass. Personally, as a senior, I ask whether the engineer needs help and will add comments to the pull request to help them resolve the issues.
Any engineer is expected to
git pull origin main frequently. Certainly before they
If two or more engineers are working at different things in the same repo at the same time then the Pull Request that gets approved 1st will be merged into the main branch. The other engineers will have to go through the
git pull origin main &
As long as your CICD pipeline is fast this isn't onerous. If you CICD pipeline runs for more than 30 minutes per deployment then it gets painful.
Git allows for the creation of a release package. We have workflows that auto-generate the release package for any changes to the main branch in the past week. We can choose to trigger this manually if we need to.
The release package is what gets deployed to shared environments.
For different environments we may have different release versions deployed. That doesn't matter because the release packages are built from main and main represents working code.
The other important thing is to make sure you release small units of work frequently. This de-risks releases, makes it easier to peer review and easier to spot problems early.
Perhaps the most important thing is to regard your processes and pipelines as being subject to continuous improvement. No process is perfect or fits all scenarios. If there is a pain point in the process or pipeline, work out how to improve or eliminate it. As everyone will be using the processes and pipelines, everyone benefits from this.