Questão de Engenharia de Software — Github e Gitlab — FGV 2026
Engenharia de Software›Github e Gitlab
Código
fg157221
Banca
FGV
Órgão
TJ RJ
Ano
2026
Cargo
AJ ( )
Em um servidor GitLab CI/CD, um pipeline é acionado por um push no branch 'feature/nova-funcionalidade'. O arquivo .gitlab-ci.yml que configurou o pipeline acionado não possui regras específicas para esse branch. Além disso, a variável $CI_COMMIT_BRANCH, predefinida pelo GitLab CI/CD, não foi sobrescrita em nenhum momento. Nesse cenário, o valor da variável $CI_COMMIT_BRANCH durante a execução do pipeline será:
Ao nome do branch padrão do repositório;
Bo nome do branch remoto ‘feature/nova-funcionalidade’;
Cnulo, pois essa variável estará desativada para esse branch;
Do nome do branch local onde o commit foi originado, prefixado pelo upstream;
Eo nome do branch local onde o commit foi originado, sem informações de upstream.
Revelar gabarito e comentário▾
GabaritoB — o nome do branch remoto ‘feature/nova-funcionalidade’;
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
GitLab CI/CD: variáveis predefinidas e o valor de $CI_COMMIT_BRANCH
Gabarito: letra B. Em um pipeline GitLab CI/CD acionado por um push em um branch, a variável predefinida $CI_COMMIT_BRANCH contém o nome do branch remoto que disparou o pipeline — no caso, feature/nova-funcionalidade. Essa é a documentação oficial do GitLab: a variável é definida para pipelines de branch e reflete exatamente o branch do commit que originou a execução.
O GitLab CI/CD injeta automaticamente uma série de variáveis predefinidas em cada pipeline, e $CI_COMMIT_BRANCH é uma das mais utilizadas. Ela é populada com o nome do branch do commit que acionou o pipeline, e esse valor vem do repositório remoto — ou seja, é o branch que existe no servidor GitLab, não uma referência local do desenvolvedor. No cenário descrito, o push foi feito no branch feature/nova-funcionalidade, e como não há regras específicas no .gitlab-ci.yml que alterem esse comportamento, a variável simplesmente carregará esse nome.
É importante entender a diferença entre o que o GitLab conhece e o que o Git local conhece. Quando você faz um push, o GitLab recebe o commit e o associa ao branch remoto correspondente. O pipeline é criado a partir desse contexto remoto, e as variáveis predefinidas refletem esse contexto. Por isso, $CI_COMMIT_BRANCH não depende de configurações locais, como upstream ou branch local de origem — o GitLab só enxerga o branch remoto.
A pegadinha desta questão está em confundir o contexto remoto (que o GitLab usa) com o contexto local (que o desenvolvedor vê). Alternativas que mencionam "branch local", "upstream" ou "branch padrão" tentam induzir o candidato a pensar em conceitos do Git local, mas o GitLab CI/CD trabalha exclusivamente com o branch remoto que disparou o pipeline. Além disso, a variável não fica nula para branches não padrão — ela é preenchida para qualquer branch que tenha um pipeline associado, a menos que o pipeline seja de tag ou merge request, casos em que outras variáveis são usadas.
Guarde o critério decisivo: o valor de $CI_COMMIT_BRANCH é o nome do branch remoto que acionou o pipeline, independentemente de configurações locais ou do branch padrão. É exatamente essa distinção que separa a alternativa correta das demais.
Afirma que a variável conteria o nome do branch padrão do repositório. Isso só ocorreria se o pipeline fosse acionado por um push no branch padrão (geralmente main ou master). Como o push foi em feature/nova-funcionalidade, o valor é o desse branch, não o do padrão. A banca tenta confundir com a ideia de que pipelines sempre rodam no branch principal, mas não é o caso.
Alternativa B — ✅ Correta ⟵ GABARITO
A variável $CI_COMMIT_BRANCH é predefinida pelo GitLab e contém o nome do branch remoto que originou o pipeline. Como o push foi em feature/nova-funcionalidade, esse é exatamente o valor. Não há regras no .gitlab-ci.yml que alterem isso, e a variável não foi sobrescrita, então o comportamento padrão se aplica.
Alternativa C — ❌ Incorreta
Diz que a variável seria nula para esse branch. Isso é falso: $CI_COMMIT_BRANCH é preenchida para pipelines de branch, independentemente de ser branch padrão ou não. Ela só fica vazia em pipelines de tags ou merge requests, onde outras variáveis (como $CI_COMMIT_TAG ou $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME) são usadas. O enunciado deixa claro que é um push em um branch, então a variável tem valor.
Alternativa D — ❌ Incorreta
Menciona "branch local onde o commit foi originado, prefixado pelo upstream". O GitLab CI/CD não usa conceitos de upstream ou branch local — ele trabalha com o branch remoto que recebeu o push. O valor de $CI_COMMIT_BRANCH é simplesmente o nome do branch remoto, sem qualquer prefixo ou informação de upstream. Essa alternativa mistura conceitos do Git local com o contexto do servidor.
Alternativa E — ❌ Incorreta
Também fala em "branch local onde o commit foi originado, sem informações de upstream". Novamente, o GitLab não conhece o branch local do desenvolvedor; ele conhece o branch remoto. O valor é o nome do branch remoto, que é exatamente o que a alternativa B afirma. A diferença é que a E tenta inserir a noção de "branch local", que não se aplica ao contexto do GitLab CI/CD.
NÃO CAIA NESSA!
A banca explora a confusão entre o contexto local do Git (branch local, upstream) e o contexto remoto do GitLab. Lembre-se: o GitLab CI/CD só enxerga o branch remoto que disparou o pipeline. Se o enunciado diz "push no branch X", o valor de $CI_COMMIT_BRANCH é X, sem rodeios.
NÃO CAIA NESSA!
Para questões sobre variáveis predefinidas do GitLab, decore o trio: $CI_COMMIT_BRANCH (branch do push), $CI_COMMIT_TAG (tag do push) e $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME (branch de origem do MR). Se o pipeline é de branch, a primeira é preenchida; se é de tag, a segunda; se é de MR, a terceira. Isso resolve a maioria das pegadinhas.