When you install a managed package in an org, you may choose as best practice to also commit to source control. When you commit your managed package to source control, there are 2 parts that you can commit:
The
Installed packagemetadata typeThe associated metadata related to that managed package (e.g.
Custom objectsorLayouts)
As an example, when you install the DocuSign eSignature for Salesforce package, it will also add associated Page Layouts, Apex Classes, and Custom Objects into your org.
You can choose what to commit and version control in your repository:
Just the
Installed packagemetadata. Conveniently, when you deploy this from Git to a target org, the associated metadata will automatically be installed in your target org even without the associated metadata in your source Git branch. This makes deploying managed packages into target orgs super easy.
Just the associated metadata. This is unusual, but there is little to stop you from doing this. This is not recommended as a way to install managed packages from source control to orgs.
Or both the
Installed packagemetadata and the associated metadata. Here, you can be selective as to which managed package metadata you choose to deploy to source control; for example, deploying the custom fields that were added by the package to standard layouts or that you will add to custom layouts. Deploying any modified standard layouts is also a good idea. Essentially, you want to anticipate what further customizations you will be making that will reference managed package metadata objects and hence Gearset's problem analyzers will be looking for their presence in the source of a future compare.
If you are looking to remove the managed package from your repository, it is important to know that deleting just the Installed package metadata item from the branch via Gearset will not automatically remove the associated metadata types for that package from the repository (as there is no information in the repository that will link the metadata to the package).
Note that if source control has no entry for the Installed package, and the target of the compare is an org with that managed package installed, Gearset detects the deletion and, if selected for deployment, will uninstall the managed package in the target org (provided there are no dependencies that first must be resolved). This includes any Git to target org set up in continuous integration (CI).
To clean up the metadata in your source control repo, you may need to run a second manual compare using an org where the package is uninstalled as the comparison source. Gearset will show, in the Deleted tab, all the metadata entries in source control that were deleted in the source org. When you deploy these deletions, your repo will be cleaned up. Any CI jobs you have set up on your repo will of course execute but since the target CI org should have already uninstalled the package, the CI compare between the repo and the CI org will find no differences as both repo and CI org have the package's metadata removed by this point.