I think in my ideal world, I would be able to make my own branch for my modifications, make changes, then commit them to the server when ready (thus deleting the branch). But if I want to be able to do that, I think we need to aim for a single-user environment, which means some sort of IRIS instance on my machine, or a dedicated environment just for my new branch on the server (as you suggested), although I don't quite understand how that would work.

This process is exactly what I was suggesting. Each developer gets their own IRIS, like they have their own copy of the code in the dedicated branch for the feature. Think of IRIS as the SDK, like the JDK for Java or Node.js for JavaScript. Your setup is complex, but if you have a process to set up your shared dev server then you can have the devs run that to set up their own servers. If developers won't be running tests that require the full setup, then the instance setup becomes even simpler. You can then have a CI/CD pipeline in your git provider that moves code to the shared test instance when it's committed to the main develop branch. With a setup like this, you can have as many devs working on as many projects as you like without them blocking each other. Any conflicts between changes will be resolved when the devs submit their code for a merge/pull request on your main branch.

Hi @Michael Derr, I recommend you have an isolated dev environment for each branch, whether that be a whole server or just a namespace. You can have Embedded Git configured to a different branch in each environment. Developers would then work in the environment that corresponds to the branch. This can be achieved with only server-side source control, but it also sets you up nicely to move to local source control in the future if that's a goal. 

@Tobias Krause You need to have a workspace folder with an active server connection to the same server and namespace that you are trying to export from. These checks are there to prevent you accidentally syncing the exported files with a different server or namespace. 

Hi @Stephan Gertsobbe, there is no exact equivalent for exporting an entire Studio project in a single XML file. The command I mentioned is the closest approximation. The best workaround is to use a terminal to do the export. Since you mentioned using these exports for backup and that you have server-side source control in use, I would expect that your files being tracked in source control would constitute the backup. 

Source control support for projects files themselves is limited due to the way we edit them. The Atelier REST API used by VS Code has no support for Studio Projects since the concept didn't exist in Atelier. VS Code uses SQL to modify projects instead. This mechanism was chosen for its backwards compatibility since Studio Projects users tended to be on older server versions. Source control UserActions are fired for projects, but not all of the lifecycle hooks will because we are not using object access. 

VS Code has a GUI that will help you debug REST services: https://docs.intersystems.com/components/csp/docbook/DocBook.UI.Page.cls...

For anyone else who may be interested, here is my answer to @Ricardo.AlvesdosSantos's question that I provided on the GitHub Discussion he opened:

The extension intentionally doesn't support what you want to do. You have to pick a side. Since you're using Git and are happy to edit the files on your local file system, I suggest you turn off source control on the server and fully embrace the client-side editing workflow. Your local file system will be the "source of truth" and the extension will sync files with the server on save and compile them. The only change is that instead of using IRIS to run the source control actions, you can use any number of industry-standard Git-compatible tools. VS Code works well with Git out of the box, and there are additional extensions you can install to make that experience even better. You can also use a different GUI application like GitHub Desktop or Sourcetree, or the git CLI directly.

If you're expecting those keys to be defined in the first element of the "items" array like the example code, you can do this:

If responseData.items.%GetTypeOf(0) = "object" {
  Set pResponse.COMPortalURL = responseData.items.%Get(0).portalUrl
}

This assumes that "items" will always be present and be an array. It checks if the first element of "items" is a nested object, and then sets the target object property to the value of portalUrl in the nested "items" object. You don't need to check if portalUrl is defined since referencing an unassigned key in a %DynamicObject will return the empty string instead of <UNDEFINED>.

Your #1 is incorrect. // and /**/ comments are allowed in the class body outside of member implementations. They won't be associated with a class member as a description. They are saved in the system global as part of the class though. They're technically their own class member type called UDLText, which you can see in the XML snippet in the original post.

These "Go To" options are built-in to VS Code core. While the action is the same, the concepts are different. VS Code describes a few of them here.