Git e GitHub na prática: Na lição anterior, aprendemos os principais conceitos do Git:

• repositório;
• commit;
• staging area;
• HEAD;
• branch;
• merge;
• conflito de merge.

Agora vamos começar a trabalhar como um desenvolvedor realmente trabalha em um projeto hospedado no GitHub.

O objetivo desta aula é aprender este fluxo:

GitHub
   ↓
git clone
   ↓
Criar branch
   ↓
Modificar arquivos
   ↓
git add
   ↓
git commit
   ↓
git push
   ↓
Pull Request
   ↓
Code Review
   ↓
Merge

Esse é um dos fluxos mais utilizados no desenvolvimento profissional.

Nesta lição, você aprenderá:

• a diferença entre repositório local e remoto;
• como clonar um projeto do GitHub;
• como verificar o estado do repositório;
• o que é o remote origin;
• como atualizar a branch principal;
• como criar branches de trabalho;
• como analisar alterações antes do commit;
• como usar o Staging Area;
• como criar commits claros;
• como enviar uma branch para o GitHub;
• como criar um Pull Request;
• como funciona um Code Review;
• como fazer o merge;
• como limpar branches depois da integração;
• como executar o fluxo completo de trabalho.

A meta é sair desta aula entendendo o caminho completo entre seu computador, o Git e o GitHub.

Antes de continuar, precisamos entender uma diferença muito importante.

É o repositório que está no seu computador.

Exemplo:

C:\projetos\meu-sistema

É nele que você:

• modifica arquivos;
• cria commits;
• cria branches;
• visualiza o histórico;
• testa suas alterações.

É uma cópia do repositório armazenada em algum servidor.

No nosso caso:

GitHub

Um endereço poderia ser:

https://github.com/usuario/meu-projeto

Portanto:

SEU COMPUTADOR                      GITHUB

Repositório local  ←──────────→  Repositório remoto

Git e GitHub não são a mesma coisa.

Git controla as versões.

GitHub hospeda repositórios Git e oferece ferramentas para colaboração.

Imagine que encontramos um projeto no GitHub e queremos trabalhar nele.

Precisamos trazer esse projeto para nosso computador.

Usamos:

git clone URL_DO_REPOSITORIO

Exemplo:

git clone https://github.com/usuario/meu-projeto.git

O Git irá:

1. baixar os arquivos;
2. baixar o histórico de commits;
3. baixar as referências do repositório;
4. configurar automaticamente o repositório remoto.

Depois:

cd meu-projeto

Agora estamos dentro do projeto.

Um dos comandos que você mais utilizará no Git é:

git status

Ele responde perguntas como:

• Qual branch estou usando?
• Existem arquivos modificados?
• Existem arquivos novos?
• Existem alterações no Staging Area?
• Existem commits ainda não enviados?

Por exemplo:

On branch main

Changes not staged for commit:
    modified: index.html

Isso significa:

O arquivo index.html foi modificado, mas ainda não foi colocado no Stage.

Use git status constantemente.

Uma excelente rotina é executar:

git status

antes e depois de operações importantes.

Quando fazemos um git clone, o Git normalmente cria automaticamente um remote chamado:

origin

Podemos verificar:

git remote

Resultado:

origin

Para descobrir para onde ele aponta:

git remote -v

Resultado parecido com:

origin  https://github.com/usuario/meu-projeto.git (fetch)
origin  https://github.com/usuario/meu-projeto.git (push)

Pense no origin como um apelido para o endereço do repositório remoto.

Em vez de escrever:

https://github.com/usuario/meu-projeto.git

constantemente, usamos:

origin

Imagine que você trabalhou ontem.

Enquanto estava fora, outro desenvolvedor modificou o projeto.

Se começar a trabalhar usando sua versão antiga, poderá criar conflitos desnecessários.

Por isso, antes de começar, normalmente voltamos para a branch principal e a atualizamos:

git switch main
git pull origin main

Em instalações ou projetos que ainda usam o comando clássico, também podemos encontrar:

git checkout main
git pull origin main

O git pull busca alterações do repositório remoto e as integra à branch local conforme a configuração do Git.

Visualmente:

GitHub
  ↓
Buscar alterações
  ↓
Integrar na branch local

Em projetos profissionais, normalmente evitamos desenvolver uma funcionalidade diretamente na branch principal.

Imagine que precisamos criar uma tela de login.

Primeiro atualizamos a main:

git switch main
git pull origin main

Depois criamos nossa branch:

git switch -c feature/login

Esse comando faz duas coisas:

Cria a branch feature/login
+
Muda para ela

Equivale a:

git branch feature/login
git switch feature/login

Agora:

git branch

poderia mostrar:

* feature/login
  main

O * indica a branch atual.

Use nomes que indiquem claramente o objetivo.

feature/login
feature/cadastro-cliente
feature/pagamento-pix

fix/login
fix/calculo-imposto
fix/erro-cadastro

docs/readme
docs/instalacao

refactor/autenticacao
refactor/servico-email

Assim, somente vendo:

feature/pagamento-pix

já sabemos o que está sendo desenvolvido.

Não existe uma única convenção obrigatória para todos os projetos. O mais importante é que a equipe escolha um padrão e o utilize de forma consistente.

Agora podemos modificar o projeto normalmente.

Imagine que criamos:

LoginController.java

E modificamos:

UsuarioService.java

Verificamos:

git status

O Git poderá informar:

Untracked files:
    LoginController.java

Changes not staged for commit:
    UsuarioService.java

Temos duas situações.

LoginController.java é novo.

UsuarioService.java já existia e foi alterado.

Antes de adicionar tudo ao Stage, podemos analisar as modificações.

Use:

git diff

O Git mostrará algo semelhante a:

- return false;
+ return usuario != null;

Linhas removidas aparecem com:

-

Linhas adicionadas:

+

Isso é extremamente importante.

Antes de criar um commit, acostume-se a perguntar:

O que exatamente estou colocando neste commit?

Podemos adicionar um arquivo específico:

git add LoginController.java

Outro:

git add UsuarioService.java

Ou todas as alterações do diretório atual:

git add .

Depois:

git status

Agora aparecerão como:

Changes to be committed

Significa:

Essas alterações estão preparadas para entrar no próximo commit.

Existe uma diferença importante entre:

git diff

e:

git diff --staged

O primeiro mostra alterações ainda não adicionadas ao Stage.

O segundo mostra o que está preparado para o próximo commit.

Antes de commitar, vale a pena executar:

git diff --staged

Agora fazemos:

git commit -m "Adiciona autenticação de usuários"

Evite mensagens como:

alteração
teste
coisas
ajustes

Prefira:

Adiciona autenticação de usuários
Corrige validação de e-mail
Remove código duplicado do serviço de login

Um bom histórico poderia parecer:

a82fd91 Adiciona autenticação de usuários
8dc221a Corrige validação de senha
751c891 Adiciona testes do serviço de login
52a912c Cria estrutura inicial do projeto

Isso transforma o histórico em documentação.

Para visualizar os commits:

git log

Você verá informações como:

commit a82fd91...
Author: Michel
Date: ...

Adiciona autenticação de usuários

Uma forma mais compacta:

git log --oneline

Resultado:

a82fd91 Adiciona autenticação de usuários
8dc221a Corrige validação de senha
751c891 Adiciona testes do serviço de login

Outra visualização muito útil:

git log --oneline --graph --all

Exemplo:

* a82fd91 Adiciona autenticação
* 8dc221a Corrige senha
| * 77f3911 Adiciona relatório
|/
* 751c891 Estrutura inicial

Aqui começamos a enxergar visualmente as branches.

Esse é um erro comum entre iniciantes.

Quando fazemos:

git commit

o commit foi criado no repositório local.

Temos:

Computador

A --- B --- C
          ↑
        novo commit

Mas o GitHub talvez ainda esteja:

GitHub

A --- B

Precisamos enviar o commit.

Usamos:

git push

Na primeira vez que enviamos uma nova branch:

git push -u origin feature/login

Isso significa aproximadamente:

Envie minha branch feature/login
para o remote origin.

Depois disso, normalmente podemos simplesmente executar:

git push

Agora:

COMPUTADOR                         GITHUB

feature/login                     feature/login

A---B---C        ───────→         A---B---C

Nossa branch existe também no GitHub.

No comando:

git push -u origin feature/login

o:

-u

é uma forma curta de:

--set-upstream

Ele configura uma relação entre a branch local e a branch remota.

Depois o Git passa a saber que:

feature/login local
        ↓
origin/feature/login

estão relacionadas.

Então futuramente podemos usar apenas:

git push

e, quando apropriado:

git pull

Depois que terminamos nossa funcionalidade, podemos ter algo assim:

main
 |
 A---B---C
      \
       D---E---F
             feature/login

Não queremos simplesmente integrar tudo à main sem revisão.

No GitHub criamos um:

Também chamado de:

PR

Um Pull Request significa aproximadamente:

Eu fiz estas alterações nesta branch. Gostaria que elas fossem analisadas e integradas à branch de destino.

O Pull Request é uma funcionalidade do GitHub e de plataformas semelhantes. Ele não é um comando do Git.

Normalmente um PR possui:

Exemplo:

Adiciona autenticação de usuários

Explique:

• o que foi feito;
• por que foi feito;
• como testar;
• possíveis impactos.

Exemplo:

Implementa autenticação de usuários utilizando
e-mail e senha.

Alterações:

- adiciona LoginController;
- adiciona validação de credenciais;
- adiciona testes automatizados;
- trata usuário inexistente.

Como testar:

1. Execute a aplicação.
2. Acesse /login.
3. Informe usuário e senha válidos.

Uma boa descrição reduz dúvidas durante a revisão.

Uma das funcionalidades mais importantes do GitHub é a revisão de código.

Outro desenvolvedor pode analisar seu Pull Request.

Ele pode:

• fazer comentários;
• sugerir melhorias;
• identificar bugs;
• solicitar alterações;
• aprovar o código.

Por exemplo:

if (usuario != null) {

O revisor pode comentar:

Podemos mover esta validação para um método específico?

Você modifica o código.

Depois:

git add .
git commit -m "Refatora validação do usuário"
git push

O Pull Request é atualizado automaticamente porque os novos commits foram enviados para a mesma branch.

Você não precisa criar outro PR.

Depois que tudo estiver:

✓ revisado
✓ testado
✓ aprovado

podemos fazer o merge.

O GitHub normalmente pode oferecer diferentes estratégias, dependendo da configuração do repositório.

Preserva a existência da branch no histórico e cria um commit de merge.

Representação simplificada:

A---B-------F
     \     /
      C---D

Junta vários commits da branch em um único commit antes da integração.

Antes:

C Corrige botão
D Ajusta CSS
E Corrige teste
F Finaliza login

Depois:

G Adiciona funcionalidade de login

Essa estratégia pode deixar o histórico da branch principal mais compacto.

Reposiciona os commits da branch sobre a branch de destino, produzindo um histórico linear.

O rebase é poderoso e merece uma aula própria.

Depois que feature/login foi integrada à main, voltamos para nossa máquina.

Primeiro:

git switch main

Depois:

git pull origin main

Agora nossa main local também possui a funcionalidade.

Podemos excluir a branch local:

git branch -d feature/login

E, quando a branch remota ainda existir e não for mais necessária:

git push origin --delete feature/login

Não é obrigatório manter branches de funcionalidades concluídas para sempre.

Agora já podemos visualizar todo o processo.

git switch main
git pull origin main

git switch -c feature/login

git status
git diff

git add .

git diff --staged

git commit -m "Adiciona autenticação de usuários"

git push -u origin feature/login

Criar Pull Request
        ↓
Code Review
        ↓
Correções
        ↓
Aprovação
        ↓
Merge

git switch main
git pull origin main
git branch -d feature/login

Esse já é um fluxo muito próximo do utilizado em equipes profissionais.

               GITHUB
                  │
                  │ git clone
                  ↓
                main
                  │
                  │ git switch -c
                  ↓
           feature/login
                  │
                  │ editar código
                  ↓
             git status
                  │
                  ↓
              git diff
                  │
                  ↓
              git add .
                  │
                  ↓
        git diff --staged
                  │
                  ↓
             git commit
                  │
                  ↓
              git push
                  │
                  ↓
              GitHub
                  │
                  ↓
           Pull Request
                  │
                  ↓
            Code Review
                  │
                  ↓
               Merge
                  │
                  ↓
                main

Agora vamos praticar.

Crie um repositório no GitHub chamado:

git-laboratorio

Clone:

git clone URL_DO_REPOSITORIO

Entre na pasta:

cd git-laboratorio

Crie:

README.md

Adicione:

# Meu laboratório Git

Projeto criado para estudar Git e GitHub.

Depois:

git add README.md
git commit -m "Adiciona README inicial"
git push

Agora crie uma branch:

git switch -c feature/sobre

Crie:

sobre.md

Com:

# Sobre

Este projeto é utilizado para praticar Git e GitHub.

Depois:

git add .
git commit -m "Adiciona página sobre"
git push -u origin feature/sobre

Entre no GitHub.

Crie um Pull Request:

feature/sobre → main

Analise as alterações.

Faça o merge.

Depois volte ao terminal:

git switch main
git pull origin main
git branch -d feature/sobre

Se conseguiu fazer isso sozinho, você já domina o fluxo fundamental de Git e GitHub.

Depois de concluir o exercício principal:

1. crie uma branch chamada feature/contato;
2. adicione um arquivo contato.md;
3. faça dois commits separados;
4. envie a branch ao GitHub;
5. abra um Pull Request;
6. altere novamente o arquivo local;
7. faça outro commit;
8. execute git push;
9. observe o mesmo Pull Request sendo atualizado;
10. faça o merge.

Esse exercício é importante para perceber que um Pull Request acompanha a evolução da branch.

Pode funcionar em projetos pessoais pequenos, mas dificulta revisão e colaboração.

Commits menores e coerentes são mais fáceis de revisar e entender.

Antes:

git status
git diff

Depois:

git add .
git diff --staged

Não enviou.

git commit = grava no repositório local
git push   = envia ao remoto

Git é o sistema de controle de versão.

GitHub é uma plataforma que hospeda e organiza repositórios Git.

Antes de abrir o PR, pergunte:

• estou na branch correta?
• meu código compila?
• os testes passam?
• removi arquivos temporários?
• não coloquei senhas ou chaves no repositório?
• revisei git status?
• revisei meu diff?
• os commits possuem mensagens claras?
• a branch está atualizada o suficiente para ser integrada?

Esse hábito reduz problemas durante o Code Review.

Agora entramos em assuntos progressivamente mais poderosos.

As próximas lições serão:

1. Git Fetch, Pull e Push profundamente
2. Git Restore, Reset e Revert — como desfazer alterações sem destruir seu projeto
3. Git Stash — guardar trabalho temporariamente
4. Merge avançado e resolução de conflitos reais
5. Git Rebase — reorganizando o histórico
6. Interactive Rebase — alterando, juntando e reorganizando commits
7. Cherry-pick — trazendo commits específicos
8. Tags e Releases no GitHub
9. GitHub Issues e organização de projetos
10. Pull Requests e Code Review profissional
11. GitHub Actions e CI/CD
12. Proteção da branch main
13. CODEOWNERS e revisão obrigatória
14. GitHub Projects
15. GitHub Releases e versionamento semântico
16. GitHub CLI
17. SSH e autenticação segura
18. Git Bisect — encontrando o commit que criou um bug
19. Reflog — recuperando commits que pareciam perdidos
20. Git Hooks e automação
21. Estratégias de branches: Git Flow, GitHub Flow e Trunk-Based Development
22. Como contribuir em projetos Open Source
23. Forks e Pull Requests em projetos de terceiros
24. GitHub Actions completo
25. Segurança: Secrets, Dependabot e Code Scanning

Quando dominarmos essa trilha, você não estará apenas sabendo usar git add, commit e push.

Você terá domínio suficiente para utilizar Git e GitHub como ferramentas profissionais de desenvolvimento, colaboração, automação, versionamento e entrega de software.

Nesta aula, percorremos o fluxo completo:

clone
  ↓
atualizar main
  ↓
criar branch
  ↓
editar
  ↓
status / diff
  ↓
add
  ↓
commit
  ↓
push
  ↓
Pull Request
  ↓
Code Review
  ↓
merge
  ↓
atualizar main local

A partir daqui, não vamos apenas decorar comandos.

Nas próximas lições, vamos entender o que o Git realmente faz por trás de cada operação, começando pela diferença entre fetch, pull e push.

Veja também: mais conteúdos sobre Git e GitHub.

Controlando versões com Git e GitHub

⭐ 4.8/5

Controlando versões com Git e GitHub. Produto recomendado para estudos, programação e produtividade.

R$ 39,90

Ver na Amazon Como afiliado, posso receber comissão por compras qualificadas.

Git e GitHub: Seu Código Versionado: Aprenda de uma vez por todas e sem enrolação (Programação para Iniciantes)

⭐ 4.7/5

Git e GitHub: Seu Código Versionado: Aprenda de uma vez por todas e sem enrolação (Programação para Iniciantes). Produto recomendado para estudos, programação e produtividade.

R$ 14,99

Ver na Amazon Como afiliado, posso receber comissão por compras qualificadas.

Git & GitHub Descomplicados: Do zero ao avançado: um guia passo a passo para dominar versionamento, colaboração e desenvolvimento moderno

⭐ 3.8/5

Git & GitHub Descomplicados: Do zero ao avançado: um guia passo a passo para dominar versionamento, colaboração e desenvolvimento moderno. Produto recomendado para estudos, programação e produtividade.

R$ 2,99

Ver na Amazon Como afiliado, posso receber comissão por compras qualificadas.