Hello Reuben,
You're correct that a single namespace can only have a single branch checked out at a time with git-source-control. The reason is that the namespace has one Git repository, and a Git repository cannot have multiple branches checked out at the same time.
I would consider this a feature rather than a bug. Imagine that a single namespace was associated with multiple branches, and an item has different changes on each branch. Which branch's version of the item would get loaded into IRIS? Shared development environments require there to be a single source of truth for the state of every item in source control.
For your scenario I might suggest single-user development environments. You could create a separate namespace for each developer on your server. Each namespace would have its own repository, with its own branches, cloning the same remote repository. The downside is that if two users edit the same item in different namespaces, you can end up with merge conflicts that you will need to resolve. I would highly recommend single-user environments if your developers are already comfortable with Git.
I have no knowledge of WebLink, but here's an old developer guide I found by searching the InterSystems docs website in case it is helpful: https://docs.intersystems.com/priordocexcerpts/weblinkdeveloper-42.pdf
You might use a GitLab webhook to do this. The first step would be to create an endpoint on your IRIS environments that can be called over HTTP to run the Pull method of the git-source-control API. That will deploy a change by running "git pull" and loading the changed files into IRIS. A simple way to do that is by creating a new web application with a REST handler like this:
Class MyApp.PullHandler Extends %CSP.REST { ClassMethod Pull() { do ##class(SourceControl.Git.API).Pull() } XData UrlMap { <Routes> <Route Url="/pull" Method="POST" Call="Pull"/> </Routes> }You will also need to make sure that this endpoint is network accessible to your GitLab environment, and authenticated according to your security requirements.
The second step would be to configure a GitLab webhook to call this endpoint on the event of a PR being merged. Here is some documentation from GitLab about how to do that: https://docs.gitlab.com/ee/user/project/integrations/webhooks.html