Controle de Versão

Este material complementa os slides do Tópico 04 e aprofunda o uso de Git como ferramenta de controle de versão.
O objetivo é que você entenda não apenas “qual comando usar”, mas também o que está acontecendo por trás e por que isso é importante em Engenharia de Software.

1. Por que usar controle de versão?

Imagine um TCC em grupo sendo editado via e-mail, com arquivos como:

• tcc-final.docx
• tcc-final2.docx
• tcc-final2-definitivo.docx

É quase certo que alguém vai sobrescrever o arquivo errado.
Um sistema de controle de versão é um histórico organizado de tudo o que aconteceu com o código (ou qualquer conjunto de arquivos).

Com controle de versão, você pode:

• registrar quem mudou o quê e quando;
• voltar para versões anteriores;
• trabalhar em paralelo com outras pessoas (branches);
• investigar rapidamente a origem de bugs (quem quebrou o quê).

Em projetos reais, usar Git é tão obrigatório quanto ter um compilador.

2. O que é o Git?

O Git é um sistema de controle de versão distribuído:

• Cada pessoa tem uma cópia completa do repositório (com histórico) na máquina local;
• Repositórios remotos (GitHub, GitLab, etc.) atuam como “pontos de encontro” para sincronizar trabalho;
• Você pode trabalhar offline e fazer push/pull quando tiver internet.

Principais características:

• muito rápido para operações locais;
• trabalha muito bem com branches e merges;
• garante integridade dos dados usando hashes (SHA-1 / SHA-256 nas versões mais novas).

Analogia:
Pense em um Google Docs offline: cada pessoa tem seu histórico completo, mas consegue sincronizar com um servidor quando quer compartilhar.

3. Configuração inicial

Após instalar o Git, configure o nome e e-mail que serão gravados em cada commit:

git config --global user.name "Alan Turing"
git config --global user.email "alan@turing.com"

Alguns pontos importantes:

• --global aplica a configuração para todos os repositórios do seu usuário;
• sem --global, a configuração vale apenas para o repositório atual (útil se você quiser e-mails diferentes em projetos distintos).

Essa configuração é identificação, não autenticação.
A autenticação com GitHub/GitLab normalmente envolve tokens, SSH ou credenciais configuradas separadamente.

4. Três áreas do Git

Uma chave para entender Git é visualizar as três áreas:

1. Working Directory (diretório de trabalho)
   Onde você edita os arquivos no seu sistema de arquivos.

2. Staging Area (index)
   Uma “lista de alterações” que você escolheu para entrar no próximo commit.

3. Local Repository (repositório local)
   Onde ficam os commits já registrados, dentro da pasta .git.

Analogia de cozinha:

• Working Directory = bancada onde você prepara vários pratos;
• Staging Area = bandeja onde você coloca apenas os pratos que vão sair agora;
• Commit no Local Repository = o registro no cardápio do que foi servido naquele dia.

4.1 A pasta .git

Quando você executa git init, o Git cria uma pasta oculta:

.git/

Ela contém:

• histórico de commits;
• configuração de branches, tags e remotos;
• índice da staging area.

Se essa pasta for apagada, o seu código continua lá, mas o histórico some: a pasta deixa de ser um repositório Git.

5. Estados de arquivo no Git

Cada arquivo pode estar em um de quatro estados básicos:

• Untracked: o Git ainda não está controlando esse arquivo;
• Unmodified: igual à última versão commitada;
• Modified: foi alterado no diretório de trabalho;
• Staged: as alterações foram marcadas para entrar no próximo commit.

Fluxo típico:

1. Cria/edita um arquivo → Untracked ou Modified;
2. git add → Staged;
3. git commit → volta a Unmodified com um novo “snapshot”.

6. Git Bash e navegação

Apesar de existirem clientes gráficos, o terminal ainda é a forma mais potente e usada profissionalmente.

6.1 Abrindo o Git Bash

Duas formas comuns:

1. clicar com o botão direito na pasta do projeto → Git Bash Here;
2. abrir o app Git Bash e navegar até a pasta com cd.

6.2 Comandos de navegação

Comando	Descrição
cd <caminho>	entra em uma pasta
cd ..	volta uma pasta
ls	lista arquivos da pasta atual
pwd	mostra o caminho completo da pasta

Esses comandos não são exclusivos do Git; fazem parte da experiência de terminal (bash).

7. Iniciando um novo repositório

Para transformar uma pasta qualquer em um repositório Git:

git init

• você precisa estar dentro da pasta desejada (verifique com pwd);
• a pasta não pode já ter um repositório Git (não pode existir .git).

É válido tanto para projetos novos quanto para pastas que já têm código.

8. Adicionando e registrando alterações

8.1 git add – enviando para a Staging Area

Depois de criar ou alterar arquivos:

git add .

• o ponto (.) significa: “tudo a partir deste diretório para baixo”;
• você também pode adicionar apenas arquivos/pastas específicas:

git add src/Main.java
git add documentos/relatorio.md

8.2 git commit – criando uma versão

Um commit é um “ponto de salvamento” com:

• um conjunto de alterações;
• um autor (nome + e-mail);
• uma mensagem descritiva;
• um hash único de identificação.

git commit -m "Implementa cadastro de usuários"

Você pode adicionar uma descrição mais longa:

git commit -m "Implementa login" -m "Adiciona autenticação básica com token JWT..."

Em times profissionais, uma boa mensagem de commit:

• resume a intenção (“o que” e, se necessário, “por que”);
• evita ruídos como “arrumei coisas”, “mexi aqui”.

9. Branches

Um branch é uma linha de desenvolvimento independente.

• O branch padrão costuma ser main ou master;
• Branches permitem desenvolver novas features ou corrigir bugs sem quebrar o código estável.

Analogia de ficção científica:
Um branch é uma realidade paralela do projeto. Você pode experimentar ideias loucas naquele universo; se der certo, junta (merge) com a linha principal.

9.1 Operações básicas

# cria um novo branch chamado developer
git branch developer

# deleta o branch developer (se já tiver sido integrado)
git branch -d developer

# lista branches locais e remotos
git branch -a

# troca para o branch developer
git checkout developer

# cria um branch "órfão", sem histórico anterior
git checkout --orphan developer

Na prática, você vai usar muito git checkout -b nome-da-feature para criar e já mudar para o novo branch:

git checkout -b feature/cadastro-produtos

10. Merge

merge é o processo de combinar o trabalho de dois branches.

Exemplo: juntar o branch developer em main:

git checkout main
git merge developer

Alguns cenários:

• fast-forward: main não tem commits novos; o ponteiro só “avança” para o commit mais recente de developer;
• merge commit: ambos têm commits; o Git cria um commit especial que une as duas linhas;
• conflitos: quando a mesma parte de um arquivo foi alterada de formas incompatíveis em branches diferentes.

Em caso de conflito, o Git marca trechos assim:

<<<<<<< HEAD
versão em main
=======
versão em developer
>>>>>>> developer

Você precisa editar o arquivo, decidir o que fica, remover as marcações e então:

git add arquivo_com_resolucao
git commit   # se o Git não criar o commit automaticamente

11. Repositórios remotos

Um repositório remoto é uma cópia do seu repositório hospedada em outro lugar (GitHub, GitLab, Bitbucket, etc.).

Ele serve como:

• backup;
• ponto central de colaboração;
• origem para pull/merge requests.

11.1 Clonando um repositório existente

Se alguém já criou o repositório:

git clone https://gitlab.com/rVenson/linguagemdeprogramacao.git

O comando:

1. cria uma pasta com o nome do projeto;
2. baixa o histórico inteiro;
3. configura um remoto padrão chamado origin.

Também é possível clonar de um caminho local:

git clone /c/Users/rvenson/Documents/LinguagemDeProgramacao

12. Ligando um repositório local a um remoto

Se você começou localmente com git init e só depois criou o remoto:

git remote add origin https://gitlab.com/rVenson/linguagemdeprogramacao.git

• origin é apenas um nome (convenção) para esse remoto;
• use git remote -v para listar os remotos configurados.

Depois disso, você pode fazer:

git push -u origin main

para mandar o branch main para o servidor e registrá-lo como “upstream”.

13. Atualizando o repositório local

Duas operações diferentes, mas parecidas no nome:

• git fetch: baixa as novidades do servidor (novos commits, branches), mas não muda seus arquivos nem o branch atual;
• git pull: faz fetch + integra automaticamente as mudanças no branch atual (geralmente por merge).

Fluxo comum antes de começar a trabalhar:

git pull origin main

para garantir que você está começando do estado mais recente.

14. Enviando alterações para o remoto

Depois de criar commits localmente, você publica as alterações com git push:

git push           # se o branch já tiver upstream definido
git push origin    # envia o branch atual para 'origin'
git push origin main

Para um branch novo, normalmente:

git push -u origin feature/cadastro-produtos

O -u faz com que, no futuro, você possa usar apenas git push e git pull sem precisar especificar origin feature/cadastro-produtos.

15. Arquivo .gitignore

O arquivo .gitignore, na raiz do projeto, lista os arquivos/pastas que não devem ser versionados:

• binários compilados (.class, bin/, target/);
• arquivos temporários da IDE;
• logs, caches;
• arquivos locais de configuração.

Exemplo:

# Ignora toda a pasta bin dentro do projeto
bin/

# Ignora todos os arquivos com final .import
*.import

# Ignora o arquivo project.config
project.config

Uma boa prática é usar geradores de .gitignore específicos para cada stack/IDE.
Um serviço popular é o antigo gitignore.io, hoje em:

• https://www.toptal.com/developers/gitignore

Você escolhe, por exemplo, Java, Maven, IntelliJ, e ele gera um .gitignore adequado.

16. Boas práticas em Engenharia de Software

16.1 Commits pequenos e coesos

• Prefira vários commits pequenos, cada um focado em uma coisa, a um gigante “monolito” com tudo misturado;
• Isso facilita entender o histórico e reverter apenas partes específicas se algo quebrar.

16.2 Mensagens de commit claras

Use frases no imperativo curto, em geral na forma:

• Adiciona validação de CPF;
• Corrige cálculo de imposto;
• Remove dependência não utilizada.

Evite mensagens genéricas como “ajustes”, “update”, “mexi aqui”.

16.3 Branches por tarefa

Organizar o trabalho por branches facilita revisão:

• feature/cadastro-usuarios
• bugfix/erro-login
• hotfix/falha-producao

Na integração, use Pull Requests (GitHub) ou Merge Requests (GitLab) para discussão e revisão de código.

16.4 Não versionar tudo

Use .gitignore para:

• não poluir o repositório;
• evitar subir credenciais, arquivos sensíveis ou ruído (logs, caches).

17. Fluxo de trabalho típico

Um fluxo simplificado de trabalho em um projeto Java com Git:

1. Obter o código

   git clone <url-do-repo>
   cd projeto

2. Criar um branch de trabalho

   git checkout -b feature/nova-funcionalidade

3. Implementar e testar

   • editar código;
   • rodar testes;
   • executar o programa.

4. Verificar o que mudou

   git status
   git diff

5. Preparar e commitar

   git add .
   git commit -m "Implementa nova funcionalidade X"

6. Enviar para o remoto

   git push -u origin feature/nova-funcionalidade

7. Abrir um Merge Request / Pull Request

   • pedir revisão;
   • discutir alterações;
   • integrar no branch principal (main/develop).

18. Materiais de apoio

Para praticar:

• Exercícios interativos: https://gitexercises.fracz.com/
• Git Katas (cenários práticos): https://github.com/praqma-training/git-katas
• Git Branching (visual e interativo): https://learngitbranching.js.org/
• Git Handbook (GitHub): https://guides.github.com/introduction/git-handbook/
• Guia prático em pt-BR: https://rogerdudler.github.io/git-guide/index.pt_BR.html

19. Conclusão

Neste tópico você viu:

• o que é controle de versão e por que ele é essencial em projetos de software;
• como o Git organiza o trabalho em working directory, staging e repositório local;
• como criar repositórios, fazer commits, trabalhar com branches e resolver merges;
• como configurar e usar repositórios remotos, além de ignorar arquivos com .gitignore;
• boas práticas para usar Git de forma profissional em equipes.

Dominar Git desde o início do curso torna muito mais fácil colaborar em projetos, entregar trabalhos organizados e evoluir para fluxos de desenvolvimento usados no mercado.