Git, dependências, empacotamento e publicação de aplicações

Do zero

Git é uma máquina do tempo para o código. Cada vez que você termina uma parte do trabalho, tira uma foto do projeto (um commit), com data, autor e uma mensagem dizendo o que mudou. Dá para voltar a qualquer foto, comparar duas fotos e trabalhar em paralelo em branches (linhas do tempo alternativas) que depois se juntam.

O Git tem três lugares para os arquivos, como uma mesa de trabalho, uma caixa de envio e um arquivo morto:

• Diretório de trabalho: a mesa, onde você edita.
• Área de preparação (staging, ou index): a caixa onde você põe o que vai entrar na próxima foto (git add).
• Repositório: o arquivo morto, com todas as fotos (git commit). O repositório local fica na pasta .git; o remoto (no GitHub, no GitLab) é a cópia compartilhada com a equipe (git push e git pull).

Quase nenhum programa é feito do zero: ele usa dependências, bibliotecas escritas por outros. O gerenciador de dependências (npm, pip, Maven) é a lista de compras: você diz “preciso da biblioteca X, versão tal”, e ele baixa, inclusive as dependências das dependências.

Por fim, empacotar é pôr a aplicação numa caixa pronta para instalar (um JAR, um pacote Python, uma imagem de container), e publicar é colocar essa caixa numa prateleira de onde outros possam pegá-la (um registro, como o npm, o PyPI ou um registro de containers).

Frase para guardar: add prepara, commit fotografa, push envia; o gerenciador baixa as dependências, o lock congela as versões, o pacote vai para o registro.

Em 1 minuto

• Comandos básicos: git init e git clone (começar), git status e git diff (ver o que mudou), git add e git commit (registrar), git log (histórico), git branch e git switch (branches), git merge (juntar), git push, git fetch e git pull (sincronizar).
• fetch × pull: git fetch baixa os commits novos do remoto sem mexer no seu branch; git pull é fetch seguido de merge (ou rebase).
• revert × reset: git revert cria um commit novo que desfaz outro, sem apagar o histórico (seguro em branch compartilhado); git reset move o branch para trás e, com --hard, descarta mudanças (perigoso depois do push).
• .gitignore lista o que o Git não deve versionar: dependências baixadas, arquivos gerados, segredos (.env).
• Versionamento semântico (SemVer): MAIOR.MENOR.CORREÇÃO. Muda o MAIOR quando quebra a compatibilidade, o MENOR quando acrescenta funções compatíveis e a CORREÇÃO quando só corrige erros.
• Arquivo de lock (package-lock.json, poetry.lock) registra as versões exatas de todas as dependências, inclusive as indiretas (transitivas), para que toda instalação seja igual.

Exemplo concreto: a correção da multa, do commit ao pacote

1. A correção no Git, num branch próprio:

git clone https://git.example.org/tce/calculos.git
cd calculos
git switch -c corrige-multa          # cria o branch e muda para ele
# ...edita src/calculos/multa.py...
git status                           # mostra o arquivo modificado
git add src/calculos/multa.py        # põe na área de preparação
git commit -m "Corrige o arredondamento da multa por atraso"
git push -u origin corrige-multa     # envia o branch ao remoto

Depois da revisão, o branch é juntado (merge) ao principal.

2. As dependências, declaradas no pyproject.toml do projeto Python:

[project]
name = "calculos-tce"
version = "1.4.1"                    # era 1.4.0: só uma correção, sobe o último número
dependencies = [
  "requests>=2.32,<3",               # aceita correções e novidades, nunca a versão 3
]

3. O empacotamento e a publicação:

python -m build            # gera dist/calculos_tce-1.4.1-py3-none-any.whl e o .tar.gz
twine upload dist/*        # publica no PyPI (ou num registro interno do órgão)
git tag v1.4.1             # marca no histórico o commit que virou a versão
git push origin v1.4.1

Comparação: os ecossistemas e as faixas de versão

JAR × WAR: o JAR (Java Archive) empacota classes e recursos, e pode ser executável; o WAR (Web Application Archive) empacota uma aplicação web para ser implantada num contêiner web ou servidor de aplicação, como o Tomcat (contêiner de servlets) ou o WildFly (antigo JBoss).

Como a FCC cobra

• fetch × pull e revert × reset.
• Função do .gitignore e do arquivo de lock.
• Faixas de versão (^ e ~) e dependências transitivas.
• Artefatos de cada ecossistema (JAR, WAR, wheel) e registros de publicação.

Pegadinhas

Explique com suas palavras

Explique a um colega o caminho de uma alteração no Git, do arquivo editado até o repositório remoto, e por que o arquivo de lock evita o “na minha máquina funciona”.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

Quando eu edito um arquivo, a mudança está só na minha pasta. Com git add, digo ao Git que essa mudança vai entrar na próxima foto. Com git commit, tiro a foto e ela fica guardada no meu repositório local, com uma mensagem. Só com git push essa foto vai para o repositório da equipe, onde os outros podem baixá-la.

O arquivo de dependências diz “quero a biblioteca X, de tal versão em diante”. Sem o lock, cada pessoa que instalar pode receber uma versão diferente, publicada no meio do caminho, e o programa se comporta de um jeito em cada máquina. O lock anota a versão exata de cada biblioteca, inclusive as que vêm de carona, e assim todo mundo instala exatamente o mesmo conjunto.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

Num caso sobre a gestão do código de um sistema do Tribunal, proponha: todo código no Git, com branch por mudança e revisão antes do merge; segredos fora do repositório (.gitignore e cofre de segredos); dependências com versões travadas em lock e verificadas contra vulnerabilidades (como npm audit ou uma ferramenta de análise de composição); e versões publicadas com SemVer e tag, num registro interno, para saber exatamente o que está em produção.

Fontes da lição

• Edital nº 01/2026, Anexo II, Desenvolvimento de Sistemas (fontes/edital-01-2026.txt).
• Pro Git, de Scott Chacon e Ben Straub (áreas do Git, commits, branches, revert e reset).
• Especificação do Versionamento Semântico 2.0.0.
• Documentação do npm: package.json e faixas de versão e guia de empacotamento do Python.