How to deal multiple branches (like master, dev, staging, feature-123, etc) with Helm Charts

Question

in our project we are using Umbrella Helm Charts (while I can't find any better term, as mentioned here) and I have dilemma how to manage the multiple branches over multiple Git Repositories under this concept.

I can't be only person struggling with this concept, so I like ask your experiences and solutions in the topic.

Our project structure looks like the following, we have multiple Git Repositories containing Micro Services. like the following....

Git Repository - Micro Service 1
  +-helm
    +-templates
    Charts.yaml
    values.yaml
  +-src
    +-main
      +-java
    +-test
      +-java
  build.gradle 

and a second one (n one actually)..

  Git Repository - Micro Service 2
  +-helm
    +-templates
    Charts.yaml
    values.yaml
  +-src
    +-main
      +-java
    +-test
      +-java
  build.gradle 

We have an convention in our Project that we only change the Version number of the Helm Chart for the Micro Service only if the K8s manifests are changed, not when the only change was the Java Source code, we place the Docker Image Id into the build and also the CommitId as AppVersion, so it recognisable from outside for which commit this Helm Chart is created.

Now with a pipeline, we deploy these helm charts (with the actual docker image ids) to the Helm Repository.

Then we have another Umbrella Git Repository (for lack of better word) which is orchestrating the Helm Charts of the Micro Service for all System deployments.

Git Repository - Umbrella
+-helm
  Charts.yaml
  values.yaml
  values-dev.yaml
  values-staging.yaml
  values-prod.yaml 

and Charts.yaml looks like the following

apiVersion: v2
name: umbrella
description: A Helm chart for Umbrella
type: application
version: 1.0.0
appVersion: "89WRG344HWRHHH"
dependencies:
- name: micro-service1
  version: 1.0.0
  repository: https://gitlab.xxx.com/api/v4/projects/XXXXX/packages/helm/stable
  condition: micro-service1.enabled
  tags:
    - application
- name: micro-service2
  version: 1.0.0
  repository: https://gitlab.xxx.com/api/v4/projects/YYYYY/packages/helm/stable
  condition: micro-service2.enabled
  tags:
    - application

Now life would be fine and dandy, if we would have one environment, like 'prod', or one Git Branch 'master', but while we have one Version number for the Micro Service Helm Charts (remember our convention as long as K8s Manifest does not changes, we don't change the Helm Chart Version for Micro Services and appVersion has no effect on Helm Charts dependency resolution, the branch for 'master', 'dev', 'feature-123', 'feature-987', etc would all produce the same Helm Chart Version, with different CommitId as appVersion. Of course, we can increase the Helm Chart Version for every Java Code change but keeping the Umbrella Charts in sink with that would be a crazy task).

So my potential solution to that, 'Gitlab Helm Chart Repositories' has a 'channel' property, so I can publish my charts to these channels based on the branch name of the Micro Service Repositories.

Now this would be quite straight forward for branch names that does not change like 'dev', 'staging', 'test') but what about feature branches, all the Micro Service Repositories should follow as convention the same Git Branch names, so if 'Micro Service 1' collaborating to 'feature-123', Git Repositories Micro Service 1 and Umbrella must have a branch 'feature-123' or if 'Micro Service 1' and 'Micro Service 2' are collaborating on 'feature-987' Git Repositories Micro Service 1, Micro Service 2 and Umbrella must have branch 'feature-987'. This would mean we would have 'channel's 'feature-123' and 'feature-987' in Helm Repository and I will add them to helm repo in build pipeline.

This brings us to my first dilemma and my first question, as long as I read and interpret the documentation of 'Nexus' and 'Artifactory' (these are the Helm Repositories that I have experience with it) has no concepts of 'channel', so this line of thought would tie my solution to the Gitlab Helm Repositories, which I don't want because at any moment upper management can say, we will use Nexus, or we will use Artifactory.

Does anybody knows these platforms have support for these concepts?

If this solution proves to be a dead end (because no other Helm Repository can support the concept of channels and create a new Helm Repository a feature branch is not really a solution ), my second plan is, during the pipeline for Micro Services, upload the Helm Chart with the Version of the charge changed to '1.0.0-branch-name', like '1.0.0-feature-123', '1.0.0-feature-987', '1.0.0-staging' so the Umbrella Repository would have the same branch and will implicitly add branch names to dependency versions (I can do that over a pipeline).

Do you see any KO criteria for this?

And finally, somebody out there must be facing the same dilemmas, how are you tackling these problems?