forcedotcom / forcedotcom/devops-center-roadmap

Rethink Combine WI process

Open
#159 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
27
Forks
1
PR merge metrics
No merged PRs in 30d

Description

I had an assumption that Combine WI works similarly to git merge: it merges all incoming changes into one. It appeared to be different. If you have:
- One WI that updates the component and changes a value A to value B
- And the latest WI where the same component is updated but the value remains A

The resulting combined WI will have the value A.
This process is called [winning](https://help.salesforce.com/s/articleView?id=sf.devops_center_promotion_combine_work_items.htm&type=5):
`Let’s say you discover a bug during testing or the requirements change. You create another work item that modifies the component just the way you want it, then promote this change through the pipeline. However, the source control repository doesn’t know which change is the one you really want, which causes a conflict. To address the conflict and enable you to complete the promotion, you can combine work items that share components. During the combining process, the changes are merged. The latest version of the component with the required modifications “wins” and moves forward.`

But it seems unintuitive because what happens is that you lose some changes with the only gain is that you won't have a merge conflict in the repository. I can't imagine a situation where it's an expected behavior.

This behavior should be at least properly explained in the pop-up that suggests the combination with the mention that some changes might be lost.
As an end goal, I would say this process should do the same as a git merge but with an interface to solve conflicts in DOC

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.