forcedotcom / forcedotcom/devops-center-roadmap
Rethink Combine WI process
- 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
Assessment
This issue has not been assessed yet.