Changes in feature branch not merged in promotion branch when back promoting.During the back promotion of user stories to lower environments in your pipeline, you might run into the situation where the changes in the feature branch for the user story you are back promoting are not merged into the promotion branch. Most likely, the user story you are back promoting was already promoted to production (master branch).
Cause of the problem.
This will happen if the commits which contains the changes you are trying to back promote, already exist in the commit history of the branch (environment) you are trying to back promote to.
How could it happen that the commits exist in that lower branch if the user story was never back promoted?
The following steps describe the scenario that will cause this situation.
1. A user story "A" containing the commit id "1" is promoted to production.
2. The commit id "1" is now part of the master branch commit history.
3. Before the user story "A" is back promoted to all the lower environments, a developer creates a user story "B" and makes a commit in a developer sandbox.
4. Whenever a commit is made on a user story, feature branch is created from master so, the feature branch for the user story "B" created from master will contain the commit id "1" from the user story "A".
5. During the commit process, the feature brach for the user story "B" is merged into the branch of the sandbox adding the commit id "1" to that branch.
6. When the user story "A" is back promoted to that sandbox, the commit id "1" is already in that lower branch.
Now that it's clear why the commit exist on the lower branch causing the changes not being merged from the feature branch, you might be wondering why the changes don't exist already in the lower branch if the commit is there.
Let's go back to the step #5 above. During the commit process, the feature brach for the user story "B" is merged into the branch of the sandbox adding the commit id "1" to that branch.
If there are conflicts when merging the branches and Copado auto resolve them, the changes related to components that are not part of the user story "B" will not be introduced in the lower branch but the commit id "1" for the user story "A" will still be added to the commit history since we are merging the entire branch. This will leave the source branch for that sandbox with the commit id on its commit history without actually getting the changes for that conflicting file.
How can you prevent this issue?
Once the user stories have been moved to production, you should back promote them to the lower environments as soon as possible so that the branches are up to date with the changes (and commits) that were moved to production (and the master branch).