

Seu próximo nível começa aqui
Com a Assinatura Ilimitada, você tem tudo que precisa para sua aprovação.
Com a Assinatura Ilimitada, você combina prática, teoria e método em uma única assinatura com tudo que você precisa para sua aprovação.
A construção de um repositório estruturado de versionamento e governança de modelos é uma prática recomendada em MLOps para garantir rastreabilidade, controle de implantação e execução segura de rollbacks.
Certo
Errado
Uma analista criou a branch feature/login a partir de develop. Enquanto ela trabalha, outros commits entram em develop. Quando terminar, a analista precisa integrar sua feature no fluxo GitFlow. O procedimento que a analista tem que seguir é:
Finalizar a feature fazendo merge primeiro em main e, em seguida, trazer esse merge de volta para develop.
Fazer merge periódico de develop em feature/login; quando a feature estiver concluída, mesclar feature/login de volta em develop.
Criar feature/login a partir de main e, ao concluir, mesclar direto em main, sem passar por develop.
Usar git rebase main sempre que houver novos commits e depois fazer merge de feature/login diretamente em main.
Não atualizar a branch durante o desenvolvimento e só no final usar merge --squash para juntar tudo em main.
Um técnico de TI utiliza git para versionar os scripts de automação de rede da organização. Durante uma reunião de alinhamento, a equipe discutiu os conceitos fundamentais do git para padronizar o uso da ferramenta. Analise as definições abaixo e assinale a alternativa que apresenta uma definição INCORRETA:
Commit: operação que registra um conjunto de alterações no histórico do repositório, criando um ponto no histórico identificado por um código único.
Branch: ramificação independente do repositório que permite desenvolver funcionalidades ou correções de forma isolada, sem afetar o código principal.
Pull: operação que baixa as alterações do repositório remoto e as integra automaticamente à branch local em uso.
Merge: operação que cria uma cópia completa e independente de um repositório remoto na máquina local, incluindo todo o histórico de alterações.
Push: operação que envia os commits realizados localmente para o repositório remoto, atualizando o histórico compartilhado com a equipe.
Uma equipe de Tl de uma Secretaria da Fazenda mantém o sistema de emissão de guias de arrecadação em um repositório Gil central, usando a branch main diretamente em produção. Um commit já publicado alterou o cálculo de ISS e gerou valores incorretos. A auditoria exige que o histórico da main permaneça íntegro, sem reescrita de histórico já publicado, e que a correção seja aplicada a partir do commit problemático. Considerando as recomendações usuais para desfazer mudanças em uma branch pública já compartilhada, o procedimento que está alinhado a essas exigências e, na branch main, executar
qit reset --hard HEAD-1 e depois git push --force origin main, removendo o commit incorreto do histórico remoto.
git reset --soft HEAD-1, ajustar o código de ISS, criar novo commit e finalizar com git push --force origin main.
git revert <hash_do commit_incorreto> e em seguida git push origin main, registrando novo commit que desfaz as alterações de ISS.
git rebase -i HEAD-2, excluir a linha do commit incorreto no rebase interativo e depois usar git push --force-with-lease origin main.
o cálculo de ISS em novo commit corretivo sobre o histórico atual e executar git push origin main, sem usar
Code Smells são indicadores de código de baixa qualidade, isto é, código difícil de manter, entender, modificar ou testar (Valente, 2020). Avalie o trecho de código a seguir (em linguagem JAVA).

Fonte: dados do elaborador
Assinale a alternativa que representa o code smell melhor caracterizado no trecho de código.
Métodos com muitos parâmetros.
Feature Envy.
Long Method.
Obsessão por tipos primitivos.
O versionamento de código é uma prática essencial no desenvolvimento de sistemas modernos, especialmente em projetos colaborativos. Ferramentas como o Git permitem o controle histórico das alterações, o trabalho simultâneo de múltiplos desenvolvedores e a rastreabilidade das mudanças realizadas ao longo do ciclo de vida do software, reduzindo conflitos e facilitando manutenção e auditoria.
Considere uma equipe de desenvolvimento back-end que trabalha de forma colaborativa em um repositório Git, realizando alterações frequentes no código de uma API corporativa.
Nesse contexto, assinale a alternativa que descreve corretamente uma prática adequada de uso do Git para garantir controle de versões e colaboração eficiente entre os membros da equipe.
Utilizar branches para desenvolver funcionalidades ou correções de forma isolada, integrando-as posteriormente ao branch principal por meio de merge controlado.
Trabalhar exclusivamente no branch principal, evitando branches adicionais para reduzir a complexidade do repositório.
Realizar commits diretamente no repositório remoto, sem histórico local, para garantir maior sincronização entre os desenvolvedores.
Eliminar o histórico de commits periodicamente, mantendo apenas a versão final do código para simplificar o controle do projeto.
Durante o processo de versionamento de um software utilizando o Git, um desenvolvedor executou um commit em seu repositório local. Imediatamente após a ação, ele percebeu que havia executado o comando muito cedo: esqueceu de adicionar um arquivo importante à área de preparação (stage) e escreveu a mensagem descritiva de forma equivocada. Como o commit ainda não foi enviado para o repositório remoto, o desenvolvedor deseja refazê-lo, incorporando o arquivo esquecido e corrigindo a mensagem, de modo a sobrescrever o registro anterior sem criar um commit adicional no histórico. Após adicionar o arquivo pendente ao stage, qual é o comando a se executar para atingir esse objetivo diretamente, sem a necessidade de comandos adicionais?
git commit --amend
git revert --commit
git reset --soft HEAD~1
git rebase --interactive
git restore --staged
Na construção de um aplicativo, um time de desenvolvimento com múltiplas frentes precisa reduzir risco de sobrescrita e permitir desenvolvimento paralelo de correções e novos recursos. Diante do exposto, uma boa prática em versionamento para atender o cenário apresentado é:
Realização de commit direto na branch principal sem revisão.
O uso de branches por finalidade e estratégia de merge/review.
A cópia de diretórios com data nos nomes para legibilidade.
O versionamento de código apenas no fim do projeto visando celeridade.
Um desenvolvedor de aplicações de TI está utilizando um sistema de controle de versão distribuído, o GlIT, no desenvolvimento de um aplicativo. No momento, ele precisa enviar as alterações recém-realizadas nesse aplicativo para um repositório remoto. O comando do ambiente GlT a ser usado, para tal, é o :git
pull
push
merge
status
branch
Observe a sequência de comandos do Git a seguir.
(Observações: as linhas estão numeradas apenas para facilitar a referência aos comandos; o arquivo newfile.c foi criado na linha 3; e o arquivo oldfile.c é um arquivo rastreado que já existia e foi apenas alterado na linha 4.)
1- git branch new-feature
2- git checkout new-feature
3- vim newfile.c
4- vim oldfile.c
5- git commit -a -m ‘Make a change’
No controle de versões com Git, supondo-se um repositório já existente, qual o efeito da sequência de comandos apresentada?
O branch new-feature é inicializado em um novo repositório, para o qual o conteúdo do repositório original é copiado e ao qual é adicionada a nova versão do arquivo oldfile.c, bem como o arquivo newfile.c.
O branch new-feature é selecionado e preparado para commit, o qual ocorre subsequentemente, criando uma nova versão, que contém o arquivo oldfile.c modificado, assim como o novo arquivo newfile.c.
O branch new-feature é criado no mesmo repositório e definido com espaço de trabalho, o qual contém a nova versão do arquivo oldfile.c, mas não o arquivo newfile.c.
O branch new-feature é criado no mesmo repositório e nele é criada uma nova versão, a qual contém o arquivo modificado oldfile.c, assim como o novo arquivo newfile.c.
Em uma organização, a adoção de controle de versões e de trilhas de auditoria em seus sistemas de gestão documental garante a disponibilidade da informação, pois assegura a integridade e a confiabilidade dos registros ao longo do tempo.
Certo
Errado
No âmbito de um Ministério Público Estadual, a equipe de Tecnologia da Informação desenvolveu um sistema eletrônico para gestão de denúncias recebidas pela Ouvidoria. Após seis meses de operação, a Procuradoria-Geral solicitou a elaboração de parecer técnico avaliando a conformidade do sistema com requisitos institucionais previamente definidos. Durante a análise, verificou-se que o sistema não possui trilha de auditoria detalhada sobre alterações realizadas nos registros nem mecanismo formal de controle de versionamento das modificações efetuadas pelos usuários internos. A luz das atribuições institucionais e do papel do setor técnico no assessoramento ao Ministério Público Estadual, a conclusão tecnicamente fundamentada que deve integrar o parecer é que
o parecer deve concentrar-se na descrição funcional do sistema, sendo o posicionamento conclusivo sobre conformidade institucional designado a outra área.
eventuais lacunas técnicas devem ser tratadas pela equipe de desenvolvimento e priorizadas frente ao registro formal parecer encaminhado à administração superior.
a inexistência de controle de versionamento compromete a rastreabilidade e a integridade das informações, exigindo recomendações técnicas para adequação do sistema.
o sistema atende aos requisitos institucionais do Ministério Público Estadual, pois implementa a autenticação e o registro de logs do sistema.
a ausência de trilha de auditoria pode ser compensada por backups periódicos priorizando o ajuste estrutural no sistema em segundo plano.
Durante o desenvolvimento de um sistema corporativo, a equipe de tecnologia definiu padrões de codificação, utilização de repositórios compartilhados e controle de alterações realizadas no código-fonte ao longo do projeto. Nesse contexto, podemos afirmar que:
compiladores executam programas diretamente sem geração intermediária de código de máquina.
sistemas de versionamento registram alterações no código-fonte e controlam versões do software.
paradigmas funcionais organizam programas por meio de estruturas sequenciais lineares.
estruturas de dados destinam-se ao armazenamento permanente de arquivos executáveis do sistema operacional.
interpretadores realizam processamento físico das instruções diretamente nos dispositivos de hardware.
Considerando as ferramentas Git e GitLab, qual das alternativas abaixo descreve corretamente suas funcionalidades?
O GitLab é utilizado apenas para integração contínua, e o Git é utilizado exclusivamente para controle de versão centralizado.
O Git e o GitLab funcionam de maneira semelhante, ambos sendo apenas plataformas de integração contínua, sem relação com controle de versão.
O Git é uma plataforma de hospedagem de código fonte, enquanto o GitLab é uma ferramenta de controle de versão distribuído que armazena e organiza o código.
O Git é um sistema de controle de versão distribuído utilizado para versionamento de código, enquanto o GitLab é uma plataforma que oferece repositórios, integração contínua e gerenciamento de código, utilizando o Git.
Considere um profissional que está utilizando um repositório Git. Em determinado momento, ele está diante do seguinte cenário:
•A branch main contém o commit A.
•A branch feature é criada a partir de main e recebe dois commits: B e C.
•Enquanto isso, a branch main recebe um novo commit D.
O desenvolvedor executa o seguinte comando a partir da branch feature:
![]()
Após o rebase, ocorre um conflito no commit C. O desenvolvedor resolve o conflito e executa:
![]()
Diante do exposto, assinale a alternativa CORRETA.
Após o rebase, os commits B e C são reaplicados sobre o commit D, criando novos hashes para esses commits.
O rebase reescreve o histórico da branch main, substituindo o commit D por uma versão compatível com os commits B e C.
O histórico da branch feature gera um fork e as referências anteriores a B e C são atualizadas.
Os commits B e C são mesclados automaticamente com D, preservando os hashes originais e evitando conflitos.
O grupo revisor de código-fonte das soluções da PDPJ-Br pode aceitar merge requests no código-fonte sem a necessidade de aprovação de testes, desde que a funcionalidade desenvolvida atenda às necessidades operacionais.
Certo
Errado
Um code smell é qualquer característica em um código-fonte que indica uma possível fragilidade ou problema mais profundo que pode vir prejudicar a manutenção e a qualidade do software. São exemplos de code smells, EXCETO:
Blocos de código duplicados.
Baixo acoplamento.
Comentários longos.
Métodos e classes muito extensos.
Violação à orientação a objetos.
Em um tribunal, a equipe técnica adota práticas de DevOps e DevSecOps. A equipe utiliza ferramentas de controle de versão como Gillab e GitHub, além de pipelines automatizados de CI/CD. Dentro dessa estrutura, a organização eficiente do verslonamento e da gestão de código deve considerar que
o fluxo Git baseado em branches centraliza o trabalho em main, utilizando branches secundárias apenas em siluações de exceção.
o merge entre branches deve ser conduzido manualmente, priorizando decisões da equips técnica, ainda que sem validações automatizadas vinculadas ao pipeline.
o versionamento de código deve ser adaptado de forma simplificada para projetos internos, com registro informal de alterações e controle local de mudanças.
pipelines de CUCD devem executar validações principalmente em ambientes de homologação, sendo dispensáveis na etapa de publicação em produção.
a gestão de branches seja organizada com a criação de ramificações especificas para novas funcionalidades, correções e releases, alinhando-se às boas práticas de versionamento.
O versionamento de código é uma prática essencial no desenvolvimento de software, permitindo que múltiplos desenvolvedores colaborem de forma organizada, mantenham um histórico de alterações e revertam mudanças quando necessário. O Git, um dos sistemas de controle de versão mais populares, fornece uma série de comandos que auxiliam na gestão do código-fonte. Considere o seguinte conjunto de comandos executados em um repositório Git:
git init
git add main.py
git commit -m "Adiciona o arquivo principal"
git branch nova-feature
git checkout nova-feature
echo "print('Nova funcionalidade')" >> main.py
git add main.py
git commit -m "Adiciona nova funcionalidade"
git checkout main
git merge nova-feature
Com base nos comandos apresentados, assinale a alternativa correta.
O comando git init clona um repositório remoto do GitHub para o computador local, permitindo edição e commits offline.
O comando git checkout nova-feature exclui a branch main e cria uma nova branch chamada nova-feature, que passa a ser a principal do repositório.
O comando git commit -m "Adiciona nova funcionalidade" altera permanentemente o arquivo main.py na branch main, independentemente de qual branch esteja ativa no momento.
O comando git add main.py faz o commit automático do arquivo main.py, sem a necessidade de um git commit.
Após a execução dos comandos, o código escrito na branch nova-feature foi incorporado à branch main por meio do comando git merge.
Ainda a respeito da situação hipotética apresentada, assinale a opção que apresenta a prática correta de versionamento que o desenvolvedor deveria ter adotado para evitar conflitos no código.
fazer as alterações diretamente na branch principal (main ou master) para acelerar o desenvolvimento
apagar o repositório remoto e criar um novo com as modificações já aplicadas
baixar o repositório em formato ZIP, editar o código localmente e enviar o arquivo por e‑mail ao líder técnico
criar uma nova branch para suas alterações, realizar commits frequentes e solicitar um pull request para revisão antes da integração
substituir os arquivos conflitantes manualmente sem utilizar comandos de versionamento, a fim de resolver os conflitos de código o mais rapidamente possível