Changes in the Feature Branch Are Not Merged in the Promotion Branch

When working with user stories and Git, you might notice that a component that is present in the feature branch is not being merged into the promotion branch and, therefore, it is not deployed. Although this is not likely to happen, there could be 2 scenarios that could lead to this situation:

1. The component exists in the feature branch but not as a change:

Let’s suppose you are working with the Pipeline below:
Dev >>> UAT >>> Prod
You need to remove the piece of code ‘Line3’ in the class below in the Dev, UAT and Prod environments.

 



After removing ‘Line3’ in Dev, the class is committed in the US-001. This is what you see in the commit in the feature branch:

The changes are promoted and deployed to UAT. The line that is removed in the feature branch is removed also in the promotion branch. When the deployment is executed, this is how the class looks like in Dev and UAT.
 

Now you realize that the line you removed must exist in the class and also Line6 must be added. You stop the promotion of the US-001, go back to the Dev organization and add the Line3 and one extra Line6 to the class. This is your class now in Dev.
 

A new user story US-002 is created to move the new additions to UAT and Prod. The class is committed in the user story, and this is how the commit in the new feature branch looks like:
 

You can see in the commit that ‘Line6’ and ‘Line3’ are there as expected, but there is a difference between them. ‘Line6’ was added. ‘Line3’ was already there because it was never deleted in the master branch. Remember that you only promoted and deployed US-001 to UAT, never to Prod.

Because ‘Line3’ is not an addition in the feature branch, if you promote and deploy the user story US-002, ‘Line3’ will not be added to the promotion branch and, therefore, it won’t be deployed to UAT.
 

 

In summary:

Only the additions or deletions in the feature branches are merged into the promotion unless there is a conflict during the merge that Git is not able to resolve, and it forces Copado to auto resolve the merge by overriding the destination with the source file. For more information check out the article Conflict Resolution with Git Integration.
If you make modifications in a component which is not up to date in master branch, you might run into this issue.

The way to proceed here would be to move US-001 from UAT back to the Dev environment and commit the new changes (the addition of ‘Line3’ and ‘Line6’) in that user story so that the commit is done in the feature branch where ‘Line3’ was originally deleted. This way, both lines will be added in the commit and merged into the promotion branch.

Another option is to set the Base Branch in the new user story as the UAT branch so that the commit is made in a feature branch created from UAT, which doesn't contain Line3.

2. The commit Id that generated the changes in the feature branch already exists in the commit history of the destination branch although the changes are not there:

A new field in Dev org is committed in a feature branch and promoted on May-18 to UAT. This commit has its own unique commit Id. The user story is moved from Dev to UAT, the feature branch is merged into the promotion branch and the latter is merged into the UAT branch. Now, the commit Id that created that field exists in the commit history of the UAT branch.

Later on, that field is removed somehow from the UAT branch. The field is no longer there, but the commit Id that created the field is still in the commit history of the UAT branch.

The user story that was used to move that field from Dev to UAT is now sent back to the Dev organization again in order to add some extra changes.

Now on May-29, the user story with the same feature branch containing the same field (and the same commit Id for that field) is moved again to UAT. The feature branch is merged into the promotion branch created from UAT which doesn't contain the field (it was deleted somehow), but it contains, in the commit history, the commit Id that created that field initially back on May-18.

Because the exact same commit Id already exists in the commit history of the promotion branch (created from the UAT branch), that specific field created with that commit Id is not going to be merged. Git is detecting the same commit Id and thinks it's not necessary to merge that field again. The field exists in the feature branch but is not being merged into the promotion branch. You can even see the field as a change looking at the commit Id that added the field into the feature branch, but it won't be merged into the promotion branch.

This kind of issue might happen when user stories are moved back after being promoted to higher environments.

Creating a pull request directly in Git between the feature branch and a test promotion branch cloned from UAT will show the same results that you see after promoting the user story.

In order to move that field, you will have to commit it again in a new user story so that a new commit Id is generated, which will allow the field to be merged into the promotion branch.


How did we do?