Set up Git in IntelliJ with Illuminated Cloud

Question

I’m new to source control (git in our case) and have just set up a development flow with CI using Gearset. That’s all well and good (and working fine). But, I also want to set up VCS within my IDE (IntelliJ with Illuminated Cloud) so that I don't have to make commits via Gearset. We're not using SFDX, if that matters.

I’ve tried several different configurations but I don’t think I’ve got it. Is my /src directory in the Illuminated Cloud project supposed to be my local repo? If so, I’m not sure how to make it work. I’ve cloned our remote repo to that directory, but then I’ve got a bunch of files that aren’t in my IC subscribed metadata types, not to mention the fact that I don’t really want all the source control metadata types in my IC project anyway.

If my IC /src directory shouldn’t be the cloned repo…then should I just initialize it as a new repo? I like this, but then I’m not sure how to create or make commits to a branch of our remote repo…which I suppose would also be locally cloned…somewhere?

Answer 1

I have a similar setup as you. Using Gearset and Illuminated Cloud.

But, I also want to set up VCS within my IDE (IntelliJ with Illuminated Cloud) so that I don't have to make commits via Gearset

I think an answer you're overlooking is: you can use both to push in different types of changes. I don't use Illuminated Cloud to push everything to github. I try to use both to their strengths and that makes my life easier:

1. Use IC (Illuminated Cloud) to push code/declarative changes

2. Everything else (typically UI changes), I use Gearset.

Why? It can be difficult retrieving in the right info regarding profiles or dependencies between UI changes. This is one of the benefits of Gearset, it simplifies (ex. profiles) and makes it easy to see the difference and add in exactly what you want. That saves me time. If you have both tools, there's no reason to not use both when it suits you. A simple "pull" in the IDE will bring in all the changes you pushed from Gearset

---

In regards to IC (and if you did want to do it all in there)

1. The support from Scott is great. If you put in questions, he answers super quickly.
2. Your metadata subscription in IC is not the end-all. If you keep the subscription small (just apex), but decide you want to retrieve changes you made in the UI, you can select "Custom" for contents and manually select metadata types from the Salesforce connection regardless of what your subscription is. This is the way I retrieve UI changes I make ad-hoc (and likely just need to retrieve once) as opposed to having my subscription selecting "all" or worrying about it containing everything I'm working on in the UI.
3. You can right click on any metadata in the IDE and select Illuminated Cloud --> Add to metadata subscription at any point to keep your subscription up-to-date as you work and realize you're touching different metadata types in the UI.
4. For point 2 and 3, make sure you're retrieving exactly what you need (which is why I prefer to do it with "custom" vs. selecting a subscription from the get-go). You can "retrieve for merge" to make sure you're only accepting the addition you want for cases where you don't have granular control at the metadata level (ex. custom labels). Same goes for profiles to make sure you're only adding to the profile. If you retrieve a profile and let it overwrite it will only contain the contents of that retrieval scope (object + profiles = only object permissions) while your source control will contain everything in the profile (ex. apex permissions, layout permissions, etc). Git diffs will help see these types of mistakes and makes it easy to revert/rectify.
5. Analyze whether there's anything else you can remove in source control to limit # of files in case you do want a subscription to include a lot of it (ex. list views, reports, dashboards, email templates). This could help speed it up on retrieval.
6. If you did want an easier way to just have a subscription set and forget it: I wouldn't use an "All" retrieval scope within IC, but I would make one specific to your source control contents containing all (or most) of what's in there. That should be less than using "all" metadata types.