Git e GitHub para iniciantes: entenda sem decorar

Git é um sistema de controle de versão: ele registra a evolução dos arquivos de um projeto. GitHub é uma plataforma que hospeda repositórios Git e adiciona recursos de colaboração. Eles trabalham juntos, mas não são a mesma coisa. É possível usar Git sem internet e sem GitHub.

Repositório, alterações e histórico

Um repositório é um conjunto de arquivos acompanhado pelo Git. O sistema registra snapshots do projeto: arquivos podem estar sem alteração, modificados ou preparados na área de staging para o próximo registro. Um commit identifica um snapshot com autor, data, mensagem e relação com o histórico anterior. Ele não é apenas “salvar”: é registrar uma etapa coerente do trabalho.

Um fluxo básico e seguro

1. Modificar: edite os arquivos necessários.
2. Revisar: confira o que mudou.
3. Preparar: selecione apenas as alterações relacionadas.
4. Registrar: crie um commit com mensagem clara.
5. Sincronizar: envie ao repositório remoto quando fizer sentido.

git status
git add nome-do-arquivo
git commit -m "Adiciona página de contato"
git push

git status deve ser consultado com frequência. Ele mostra a branch atual e o estado dos arquivos, reduzindo erros por falta de contexto.

Local e remoto

Clone cria uma cópia local de um repositório remoto. Push envia commits locais. Pull busca alterações e tenta integrá-las ao trabalho local. Antes de enviar, é importante buscar o que a equipe publicou para reduzir divergências.

Branches e merge

Uma branch é uma linha de desenvolvimento. Ela permite criar um recurso ou corrigir um defeito sem mexer imediatamente na linha principal. Quando o trabalho é revisado, suas mudanças podem ser integradas por merge.

Conflito ocorre quando o Git não consegue decidir sozinho como combinar alterações. Não é uma falha misteriosa: o arquivo mostra as partes concorrentes e uma pessoa deve escolher a versão correta, testar e registrar a resolução.

Pull request

Em plataformas como o GitHub, um pull request propõe integrar uma branch. Ele permite discutir, revisar arquivos, executar verificações automáticas e registrar decisões antes da mudança chegar à branch principal.

O que nunca deve ir para um repositório público?

• senhas e chaves privadas;
• arquivos com credenciais;
• dados pessoais de clientes ou estudantes;
• segredos de serviços externos;
• arquivos grandes gerados que não pertencem ao código.

Um arquivo .gitignore impede que padrões desnecessários sejam incluídos, mas não remove um segredo que já foi publicado. Nesse caso, a credencial precisa ser revogada e substituída.

Laboratório local: construa um histórico que explique o projeto

Você pode praticar Git sem publicar nada. Crie uma pasta chamada lista-estudos, adicione um arquivo README.md com o objetivo do projeto e execute git init. Consulte git status antes e depois de cada etapa; esse hábito mostra exatamente o que será registrado.

git init
git status
git add README.md
git diff --staged
git commit -m "Documenta objetivo da lista de estudos"

Depois acrescente uma lista de três temas ao README, confira a diferença com git diff e faça um segundo commit. Corrija uma palavra e registre a correção separadamente. Ao final, use git log --oneline: as três mensagens devem permitir entender a evolução sem abrir os arquivos.

Um projeto versionado ainda precisa de cópias recuperáveis. Entenda por que Git e hospedagem remota não substituem sozinhos um plano de backup.

Caso completo: duas pessoas alteram o mesmo projeto

Ana corrige o formulário enquanto Bruno melhora o relatório. Se ambos editarem diretamente a mesma versão e enviarem arquivos por mensagem, fica difícil saber qual cópia é a correta. Com Git, cada mudança pode ser registrada em uma branch e integrada de forma explícita.

git switch -c corrige-formulario
# editar e testar
git add formulario.html
git commit -m "Corrige validação do formulário"
git push -u origin corrige-formulario

O pull request não é apenas um botão de publicação: ele mostra a diferença, registra discussão e permite verificar o código antes de integrar. A documentação oficial do projeto está disponível gratuitamente no livro Pro Git.

Como entender um conflito

Conflito significa que o Git não conseguiu decidir sozinho como combinar alterações que atingem a mesma região. A pessoa precisa ler as duas intenções, produzir a versão correta, testar e então registrar a resolução. Aceitar sempre “a minha versão” ou “a versão deles” pode apagar trabalho válido.

1. Leia o arquivo e identifique as marcações de conflito.
2. Converse com quem produziu a outra alteração quando a intenção não estiver clara.
3. Edite o resultado final e remova as marcações.
4. Execute os testes ou abra a página afetada.
5. Use git add e conclua o commit da resolução.

Commits que explicam o projeto

Um bom commit representa uma mudança coerente e possui mensagem específica. “Corrige cálculo da comissão no fechamento” é mais útil do que “alterações”. Evite misturar formatação, nova funcionalidade e correção de erro no mesmo registro quando elas podem ser separadas.

Perguntas frequentes