This would be extremely helpful when it comes to Layout components. It is often when working on a large project that it will fall behind new fields that are being added to page layouts due to other ongoing work. The ability to choose that I want to keep those fields on the layout in the target org as well as add the new fields from the source org to the layout would be immensely beneficial.

Yes, this feature will be very helpful
Do a compare and deploy in between two sources [1st and 2nd - can be GITHUB or sandbox or others]

Scenario:
How it will help devs for delta ?
Compare results --> Select New, Change and Delete --> Problem Analysis --> Deployment Summary --> Add notes -->
Do a commit of delta/diff to 3rd target source [can be GITHUB / others]

OR

Validate & deploy delta/diff to target sandbox

Note: It will be developer's responsibility to have the right code in 1st source

I just started using Gearset, it have lots of great features, but this one missing for me is big drawback. It will push it to next level, I can imagine it can be based on some permission, so admins can control who can use it, but definitely needed.
I believe this is huge improvements for code, but also for configurations such as apps, lightning record pages, approval process etc.
Some use cases from last days:
I am working on approval process, done all stuff and ready for deployment. In comparison I can see there is some other change which I didn't made. It was work done by my colleague on another ticket and it is also already ready for deployment, so no problem I can deploy. But there can be ongoing work on components and then its almost impossible to deploy only my changes, which are ready for deployment.
Another issue is, that sometimes environments doesn't match same release and some "lines in metadata" are not supported anymore, so without this option again almost impossible.
As workaround I will try to edit metadata locally in VS Code and then compare with my local file, I hope it will work smoothly...

Hi,

Can we get the ability to merge changes between source and target? Right now you have to choose either source or target to be deployed and whichever you choose overwrites the entire class.

When you merge code in git you can take your source code, compare it with your target code and then you can choose the differences you want to keep or discard within that one class, file or trigger.
This will be displayed in a third window called results.

That would make Gearset Awesome :D !!!!

This is a must have feature for developer. Having built into Gearset will save us tremendous amount of time and make our lives a lot easier.

Allow me to post merging feature from a competitive product:
https://bluecanvas.io/blog/how-to-solve-merge-conflicts-in-salesforce

Also, this feature has been under review since March 2016. We need this feature so badly.

I would like to add to this topic the need to be able to select lines of code to include in the deployment. We do not have VCS yet and many developers working on their not often refreshed sandbox makes the comparison harder and we tend to overwrite someone's code or changes already deployed in production.

My workaround is very long by comparing 2 orgs, validate and then download the XML, to be edited outside of Gearset, and use the edited XML as the base in another comparison for deployment.

This would tremendously help us if we are able to select the lines of code instead of the whole file, especially in Profiles, permissions, apex.

One of the advantages of working with Metadata rather than built in change sets is the ability to intelligently decide which lines we want to move forward, rather than to clobber entire files and/or contain unimportant or even undesirable artefacts of the development process which should only live and die in the development sandbox.

Without merge tools, using Gearset to modify our git repository has been making the repository somewhat dirty.

Also, as/if/when my solving problems outpaces my manager who thoroughly reviews my code, I'm finding work done in Sandbox A becomes incompatible with Sandbox B, requiring me to perform merges on my own machine rather than in Gearset.

I'll add my comment here, for my use case it's around Page Layouts. Being able to select a new field to be merged into the layout vs. the layout replaced would be phenomenal.

If there were a way to choose to merge or deploy (overwrite/deploy the diff), it would allow us to deploy Page Layouts to our active orgs.

To the prior question as to where this would be most helpful - for us, Profiles, Permission Sets, layouts, and Apex code.

This would be soooo helpful. We use the fflib Enterprise Architecture pattern wherein there are domain classes for each sobject, service classes (typically by sobject) and selector classes (also by sobject). Plus a common Application.cls.

All it takes is two developers working on stories that both affect the same aforementioned Enterprise Architecture class file and it requires way too much out-of-band work to resolve merges due to timing issues between when the feature sandbox/branch was created and the current master branch.

Since we do PRs before merging into master, the PR reviewer is apt to say "hey, you are wiping out changes I made in master". Though resolvable with GITHub merge it would be best to avoid that step before the PR is presented for review.

Being able to selectively 'not' deploy a block of code from source to target (because target is more current) would be helpful. For us, this is typically just Apex class files but I can appreciate the point about page layouts as well

Another scenario where this is a problem are things that are commonly shared between features such as Page Layouts. 2 configurators are working on separate changes with fields on on a Contact Page Layout; one finishes their work, the other doesn't. If the person who finishes deploys the Layout before the other is ready, we're now in a situation where we have to rollback or they are both blocked from deployment until both are finished.

It would be great to be able to pick and choose which "chunks" of metadata to include in a Gearset deployment so that you could avoid this scenario. The complete feature would be selected to move forward while the incomplete one would not.

There's no good way to handle this scenario outside of manual release management & human review, so if Gearset added this it'd be a huge help!

Kevin, I'm thinking of a team development flow where two developers work in their own development sandboxes and then use Gearset to promote their changes to an integration sandbox. If they have both made changes to the same Apex class, it would be cool for the second developer that deploys to be able to do the diff and merge right in Gearset.

Scott, what object types do you anticipate needing this for most? For things like profiles, we are breaking them up into their smaller components which reduces the need to merge those objects hopefully as we'll take care of the merging under the hood.

Which object types have you had to merge manually?

Kevin

Without this feature built into the tool, I imagine the flow would work like this:
- Do a comparison with the dev sandbox as the source and the integration sandbox as the target
- Examine the diffs for each component looking for conflicts
- Manually merge any changes we don't want to overwrite into the component in the dev sandbox outside of the tool
- Refresh the comparison in the tool (assuming the refresh action pulls the updated metadata)