[DÚVIDA] Variáveis de ambiente

Na verdade... o seu .env tem que funcionar com os valores pertinentes para cada ambiente.

Deveria ter um .env.prod, .env.local, .env.dev... e assim por diante. Em teoria, as variáveis do .env real que rodam em produção deveriam ser conhecidas apenas por quem faz o deploy em produção, por quem gerencia as pipelines, etc.

Localmente, você deveria ter um .env que não tivesse nem um resquício das variáveis que são usadas de verdade e que todos os membros do projeto deveriam ter acesso e que poderiam inclusive ir para o repositório.

Vamos supor que você tem:

.env.example -> tem que estar no repositório

HOST_SERVICE_A=
AUTH_KEY_SERVICE_A=

.env.local -> pode ir pro repositório

HOST_SERVICE_A=localhost:8002
AUTH_KEY_SERVICE_A=uma_key_local_sem_importancia

.env.prod -> nunca jamais deve estar no repositório

HOST_SERVICE_A=host_servico_a_prod.com.br
AUTH_KEY_SERVICE_A=uma_key_secreta_que_ninguem_saberia_e_estaria_na_pipeline

.env.dev -> talvez possa estar no repositório

HOST_SERVICE_A=host_servico_a_homolog.com.br ou host_servico_a_mockado.com.br
AUTH_KEY_SERVICE_A=uma_key_de_homologação_ou_do_mock_que_é_menos_sensivel

Perceba que em todos esses casos, a variável do prod (sejam elas quais forem, aqui eu dei só o exemplo da url de um serviço) NUNCA foi exposta para os outros contextos. Se você for subir o serviço A localmente, você passaria o endereço localhost. Mas se isso fosse impossível, você usaria um ambiente de homologação ou um Mock, mas não o ambiente que se usa em produção.

Se seu projeto não possui essa organização então obrigatóriamente você precisa caçar esses valores pra conseguir trabalhar, mas é uma má prática de segurança que seja necessário saber os valores reais para conseguir desenvolver alguma coisa.

"está certo eu ser obrigado a buscar todas as infos necessárias, uma por uma?"

não sei o resto do contexto...mas se essa foi a tarefa que foi alocada para que você realize, me parece que não tem outra saida..

chegou a questionar os outros devs do time se alguem tem um .env para compartilhar contigo? certamente vc nao é o primeiro que está passando por isso. por outro lado,
dependendo da stack é bem tranquilo descobrir os nomes das variaveis, e depois entender quais os valores que deveriam ter.

váriaveis de ambiente para ambientes de dev (local) e homologação podem ser fácilmente compartilhadas em git, dado que não interferem no sistema PRD caso vaze alguma coisa e podem ser facilmente trocadas, já que na real não vai impactar o usuário

váriaveis para PRD já entra numa area complexa que vai depender do que seu time possui a disposição, ja trabalhei com duas situações:

• Pipeline com key vault que "preenchiam" as variaveis no arquivo .env que ia para o servidor de produção
• Servidor de provisionamento (que tinha um acesso bem restrito) e nele estava configurada a ferramenta de IaC (ansible) e as envs encriptadas usando o ansible vault

No seu caso, o ideal seria que informações de acesso para ambientes de dev/homologação fossem versionadas e/ou compartilhadas entre o time de maneira que seu tempo para começar a programar fosse minimo, ter essa dificuldade pode ser uma questão de organização do time que não foi colocada em pauta ainda, mas que pode ser uma boa tentar pelo menos organizar essas informações , sempre dentro do que o time/empresa permite fazer claro

O dev senior responsavel pelo projeto costuma ter um exemplo na máquina local ou repo separado. Esse é o mais comum, mas em empresas maiores ou com escopo grande, (pelo que vi) se costuma dar commits esporadicos do .env