@Shirisha Boinapalliprior to 24.2 the experience was different, correct. However, the outcome was that Developer B changes from Branch B ended up in Branch A's version of pyDefault - so this wasn't a great outcome either, cross pollinating changes that needed to be unpicked prior to merge. This meant it was always good practice to try to find ways to avoid clashes:

1. Allocation of development work: Try to split the development work in a way that avoids these clashes, where possible.
   • Having one person in charge of the case lifecycle, like a BA, assembling what has been developed inside Data- or the Work- UX tab, will avoid clashes.
2. Modular: These approaches have been successful in breaking up development work in to cleaner, encapsulated development – by leaning into App Studio’s focus on the “App” you can split development in your stack between apps, mitigating clashes when all developing in one application.
   • Academy: https://academy.pega.com/mission/modular-enterprise-reuse-foundation/v1

In addition to the above good practices there are a few other things that can help mitigate clashes.

1. Case Designer: "Save and run" button is a common culprit for this, as it will save a new version of pyDefault rule. 
   • Its common practice to do this but not necessary. Clicking Save and then using Preview can achieve the same outcome without saving a new version of pyDeafult 
2. Auto-save Views (Constellation): With the introduction of Constellation, assuming you're on Constellation? Modifying Views will auto-save, so this helps avoid clashes by using Save on the case type