 |
| Bellacosa Mainframe muito alem do git commit |
☕ Um Café no Bellacosa Mainframe
Git Muito Além do git commit
O Que Todo Programador COBOL Padawan Precisa Saber Sobre Controle de Versão Profissional na Era da Inteligência Artificial, DevOps e IBM Mainframe
"Existe uma enorme diferença entre saber usar comandos do Git e compreender como o Git realmente pensa. É exatamente essa diferença que separa um programador que apenas grava código de um engenheiro de software capaz de colaborar em projetos globais."
Introdução
Recentemente encontrei uma imagem bastante interessante intitulada "Top 20 Git Commands Every Developer Should Know". À primeira vista, ela parece apenas mais um resumo para consulta rápida.
Ela lista comandos como:
git initgit clonegit addgit commitgit pushgit pull
e muitos outros.
Para um desenvolvedor iniciante, essa imagem parece representar praticamente todo o universo do Git.
Mas existe um detalhe importante.
Ela mostra o volante, o acelerador e o freio.
Ela não mostra o motor.
E quem trabalha com sistemas críticos — especialmente quem vem do universo IBM Mainframe — sabe que entender somente os comandos nunca foi suficiente.
No mundo do z/OS não basta decorar:
IEFBR14
É preciso entender:
JES2
Address Space
Dispatching
Storage
Dataset Catalog
VSAM
RACF
SMF
WLM
Da mesma forma, no Git não basta decorar comandos.
É preciso entender a arquitetura.
Hoje vamos tomar um café e mergulhar no funcionamento interno do Git.
Git não é apenas um programa
O Git é um Sistema Distribuído de Controle de Versão (Distributed Version Control System - DVCS).
Essa definição parece simples.
Mas ela muda completamente a forma como o desenvolvimento acontece.
Antes do Git existiam ferramentas como:
CVS
SourceSafe
SVN
Todas eram centralizadas.
Imagine um servidor.
Servidor
Projeto
Todos os desenvolvedores dependiam dele.
Se o servidor parasse...
Ninguém trabalhava.
Se a rede caísse...
Ninguém fazia commit.
O Git mudou completamente essa arquitetura
Quando você executa:
git clone
Você não baixa apenas os arquivos.
Você baixa:
todos os commits
todas as branches
todas as tags
todo o histórico
Na prática, você cria um espelho completo do repositório.
É como se cada desenvolvedor carregasse um mini GitHub dentro do notebook.
Fazendo uma analogia com o Mainframe
Imagine um enorme PDS onde vivem todos os programas COBOL.
Agora imagine que cada desenvolvedor possui uma cópia completa daquele PDS, incluindo todas as versões desde a criação do sistema.
É exatamente isso que o Git faz.
Só que muito melhor.
A pasta mais importante do projeto
Quando executamos:
git init
Algo aparentemente simples acontece.
É criada uma pasta escondida.
.git
Muitos iniciantes ignoram essa pasta.
Grande erro.
É nela que mora todo o Git.
Se ela desaparecer...
O histórico desaparece.
Os commits desaparecem.
As branches desaparecem.
As tags desaparecem.
O projeto volta a ser apenas uma pasta comum.
O que existe dentro da pasta .git?
Normalmente encontramos algo parecido com isto:
.git
objects
refs
HEAD
config
hooks
logs
index
packed-refs
Cada item possui uma função específica.
objects
É o verdadeiro banco de dados do Git.
Tudo fica aqui.
Arquivos.
Commits.
Branches.
Trees.
Tags.
Tudo.
refs
São os ponteiros.
Eles dizem onde cada branch está.
HEAD
É o famoso ponteiro atual.
Sempre indica onde você está trabalhando.
config
Contém toda configuração local.
Usuário.
Email.
Remotos.
Aliases.
hooks
Automação.
Podemos executar scripts antes de:
commit
push
merge
Muito usado em DevOps.
O Git não salva diferenças
Essa talvez seja a maior surpresa para quem começa.
Muitos acreditam que o Git grava apenas as linhas modificadas.
Não.
Ele trabalha principalmente com snapshots.
Imagine um diretório.
Projeto
Programa1.cbl
Programa2.cbl
JCL1.jcl
README.md
Quando fazemos:
git commit
O Git registra um retrato completo daquele momento.
Como uma fotografia.
Não apenas um patch.
Isso torna a recuperação extremamente eficiente.
Os quatro tipos de objetos do Git
O banco interno do Git possui apenas quatro tipos fundamentais.
Blob
Representa o conteúdo de um arquivo.
Não conhece nomes.
Não conhece diretórios.
Conhece apenas bytes.
Tree
Organiza os blobs.
Funciona como um diretório.
Commit
Liga uma árvore ao histórico.
Contém:
autor
data
mensagem
commit anterior
Tag
Marca um commit especial.
Normalmente versões:
v1.0
v2.0
Release-2026
SHA: a identidade única de tudo
Cada objeto recebe um hash.
Exemplo:
c83f92b15c4...
Esse hash é calculado sobre o conteúdo.
Se um único byte mudar...
Todo o hash muda.
Essa característica garante integridade.
Os três estados dos arquivos
Esse é provavelmente o conceito mais importante do Git.
Todo arquivo percorre três etapas.
Working Directory
↓
Staging Area
↓
Repository
Working Directory
É onde editamos.
Abrimos o COBOL.
Mudamos um SELECT.
Alteramos um PERFORM.
Ainda não existe histórico.
Staging Area
É uma área intermediária.
O comando:
git add
Não grava nada.
Ele apenas prepara.
É como colocar documentos sobre a mesa antes de arquivá-los.
Repository
Somente quando executamos:
git commit
O histórico realmente nasce.
Git Status
Se existisse apenas um comando obrigatório seria:
git status
Ele responde perguntas como:
O que mudou?
O que será enviado?
O que ainda não entrou no commit?
Executar esse comando diversas vezes ao longo do dia é uma excelente prática.
Git Add
Existe uma diferença enorme entre:
git add arquivo.cbl
e
git add .
O primeiro adiciona apenas um arquivo.
O segundo adiciona praticamente tudo.
Isso inclui arquivos temporários.
Logs.
Arquivos de configuração.
Até senhas esquecidas.
Daí nasce a importância do:
.gitignore
Git Ignore
Imagine esquecer dentro do projeto:
senha.txt
backup.zip
log.txt
database.db
Sem o .gitignore, tudo isso pode ir para o repositório.
Alguns vazamentos famosos de credenciais ocorreram exatamente por causa disso.
Commits são sua documentação
Existe um velho hábito ruim.
Update
Outro.
Correções
Outro.
Mudanças
Meses depois...
Ninguém sabe o que foi alterado.
Uma boa mensagem explica a intenção.
Por exemplo:
Valida CPF antes da gravação no DB2
ou
Corrige cálculo do IOF para operações acima de R$ 50.000
Muito mais útil.
Branches: linhas paralelas de desenvolvimento
Imagine um banco.
Enquanto uma equipe trabalha no PIX...
Outra trabalha no Open Finance.
Outra corrige produção.
Tudo ao mesmo tempo.
Isso só é possível porque existem branches.
main
├── feature-pix
├── feature-openfinance
└── hotfix
Cada equipe trabalha isoladamente.
Merge
Quando uma funcionalidade termina:
feature-pix
ela precisa voltar para:
main
É aqui que entra o:
git merge
Ele une dois históricos.
Conflitos
Imagine dois desenvolvedores alterando a mesma linha.
Um escreve:
MOVE ZERO TO WS-TOTAL.
Outro escreve:
MOVE WS-VALOR TO WS-TOTAL.
Quem está certo?
O Git não decide.
Ele apresenta:
<<<<<<<
=======
>>>>>>>
E cabe ao desenvolvedor resolver.
Fetch versus Pull
Muitos iniciantes acreditam que são iguais.
Não são.
git fetch
Baixa novidades.
Mas não altera seu trabalho.
Já:
git pull
Baixa e integra imediatamente.
É praticamente:
fetch
+
merge
Em projetos críticos, muitos profissionais preferem primeiro:
git fetch
Analisar.
Depois integrar.
Push
Sem ele ninguém verá seu trabalho.
git push
Envia seus commits ao servidor.
É a promoção do desenvolvimento local para o repositório compartilhado.
Git Diff
Antes de qualquer commit execute:
git diff
Você verá exatamente:
-
+
Tudo que será enviado.
Isso evita inúmeros erros.
Git Stash
Imagine este cenário.
Você está desenvolvendo uma API.
Surge uma emergência em produção.
Você ainda não pode fazer commit.
O que fazer?
git stash
Ele guarda temporariamente tudo.
Depois:
git stash pop
Seu trabalho retorna exatamente como estava.
Git Reset
Esse comando merece respeito.
Especialmente:
git reset --hard
Ele pode apagar alterações locais sem possibilidade simples de recuperação.
Não é um comando para testar.
É um comando para compreender profundamente antes de usar.
O verdadeiro poder das branches
No Git, uma branch é extremamente leve.
Ela não copia o projeto.
Ela cria apenas um ponteiro.
Por isso podemos criar dezenas ou centenas delas.
O Git e o DevOps
Hoje praticamente toda pipeline utiliza Git.
Por exemplo:
Commit
↓
GitHub
↓
GitHub Actions
↓
Build
↓
Testes
↓
Deploy
↓
Produção
Sem Git praticamente não existe DevOps moderno.
GitHub não é Git
Outro erro muito comum.
Git é uma tecnologia.
GitHub é um serviço.
Também existem:
GitLab
Bitbucket
Azure DevOps
Gitea
Forgejo
Todos utilizam Git.
Git e Inteligência Artificial
Ferramentas como:
GitHub Copilot
ChatGPT
Claude
Gemini
podem escrever código.
Mas todas dependem de algo extremamente importante.
Histórico.
Contexto.
Versionamento.
Quando uma IA gera uma alteração, ela precisa ser rastreável.
Quem alterou?
Quando?
Por quê?
Qual problema resolveu?
Git responde todas essas perguntas.
Git no universo IBM Mainframe
Durante muitos anos o desenvolvimento Mainframe utilizou ferramentas como:
Endevor
Changeman
Librarian
Panvalet
Hoje muitas empresas estão integrando esses ambientes ao Git.
Isso permite:
CI/CD
Pull Requests
Code Review
Integração com Jenkins
GitHub Actions
Azure DevOps
IBM Dependency Based Build (DBB)
Zowe CLI
VS Code
OpenShift
Ansible
O código COBOL continua executando no IBM Z, mas o ciclo de desenvolvimento passa a seguir práticas modernas de engenharia de software.
Git para um COBOL Padawan
Se você está iniciando na programação COBOL, encare o Git como uma habilidade tão importante quanto aprender:
IF
PERFORM
EVALUATE
READ
WRITE
EXEC SQL
CICS LINK
Hoje um profissional que domina apenas a linguagem perde competitividade.
As empresas procuram desenvolvedores que também entendam de colaboração, automação, revisão de código e integração contínua.
Boas práticas para o dia a dia
Algumas recomendações fazem enorme diferença:
Faça commits pequenos e frequentes.
Cada commit deve representar uma única alteração lógica.
Escreva mensagens claras e objetivas.
Nunca desenvolva diretamente na branch
main.Revise as mudanças com
git diffantes de cada commit.Consulte
git statusconstantemente.Configure um
.gitignoreadequado ao seu projeto.Prefira
git fetchquando quiser analisar alterações antes de integrá-las.Evite
git reset --hardsem compreender totalmente suas consequências.Utilize Pull Requests para revisão de código e compartilhamento de conhecimento.
Conclusão
O Git é muito mais do que uma coleção de comandos. Ele representa uma mudança de paradigma na forma como construímos software, promovendo colaboração, rastreabilidade e segurança. Para o programador COBOL Padawan, dominar essa ferramenta significa conectar décadas de experiência em sistemas corporativos às práticas modernas de DevOps, integração contínua e desenvolvimento assistido por Inteligência Artificial.
Assim como aprender JCL vai muito além de decorar //JOB e //EXEC, aprender Git vai muito além de executar git add, git commit e git push. O verdadeiro diferencial está em compreender sua arquitetura interna, seus objetos, seus fluxos de trabalho e a filosofia que sustenta um dos projetos de software mais influentes da história.
No universo Bellacosa Mainframe, o Git não substitui a disciplina que sempre caracterizou o desenvolvimento em IBM Z — ele a amplia. Ele oferece mecanismos para preservar conhecimento, facilitar auditorias, permitir revisões estruturadas e integrar aplicações legadas a pipelines modernas de entrega contínua. Em uma era em que a Inteligência Artificial acelera a escrita de código, o Git continua sendo a memória confiável do projeto, registrando cada decisão técnica e garantindo que a evolução do software seja transparente, reproduzível e segura.
O conselho final para todo COBOL Padawan é simples: não estude apenas os comandos. Estude os conceitos. Entenda como o Git pensa. Quando isso acontecer, você deixará de ser apenas um usuário da ferramenta e passará a utilizá-la como um verdadeiro engenheiro de software, preparado para atuar tanto em aplicações modernas quanto nos ambientes críticos que movimentam bancos, seguradoras, governos e grandes corporações ao redor do mundo. Afinal, tecnologias mudam, linguagens evoluem, mas a capacidade de controlar, compreender e colaborar sobre o código continuará sendo uma das competências mais valiosas da engenharia de software.
Sem comentários:
Enviar um comentário